Maven mixes many programming tools in one program: project building (make), dependency management(apt/yum), project management, etc.
I replaced maven by ant+RPM+yum+Hudson in one large project, and everybody is happy.
Maven builds are an infinite cycle of despair
41–50 of 51 posts
Re: Maven builds are an infinite cycle of despair
#42Earlier quoted context omitted.
Check out this page: http://buildr.apache.org/quick_start.html . I will paste the most relevant text below. "No knowledge of Ruby is assumed. Buildr is designed to be a very intuitive, very easy-to-use tool. You can create buildfiles which describe incredibly intricate projects, write custom tasks which do things far beyond Ant, and still never need to pick up more than a smattering of Ruby syntax." Also, learning a…
I think it depends. Is learning a new programming language a waste of time compare to getting better with the current programming language that you knew already? While I'm learning Ruby, it did not make me a better Java programmer. I still suck at Java programming. Reading books like Code Complete, Pragmatic Programmer, Clean Code, and reading Zen of Python (import this) help me to become a better programmer; but lea…
Ruby introduced me to the ideas of first class functions, closures, and higher order functions and the design patterns that can be easily implemented using them. These same patterns can be implemented in Java, albeit with a much more verbose syntax. Most Java programmers are unaware of even these basic functional concepts and it shows because they end up copy-pasting a lot of code they don't have to and writing silly functions that can be easily implemented in terms of functions like map, filter, and reduce.
Yes, learning a new language can and does make you a better programmer if it introduces new concepts you can apply to other languages.
Re: Maven builds are an infinite cycle of despair
#43Obligatory, the maven adoption curve:
Re: Maven builds are an infinite cycle of despair
#44Earlier quoted context omitted.
I think you're right that in principle one can make a maven build deterministic, but in practice I have yet to see it done. Of course, that could just be a statement about the crowd I hang out with, but I think there are more fundamental problems. Wouldn't you have to specify explicit version numbers for not only your immediate dependencies, but also all transitive dependencies? Not that that's necessarily a bad thin…
What you're missing here is sort of described in the RTFM. There are a couple very good, free books on maven that describe this, but in essence: 1) You absolutely should have your own local repository (e.g. Archiva). 2) You should use and tags to force all projects to have the same versions o all deps and plugins. 3) Don't even try using snapshots unless you know what you are doing.
A local repository doesn't address the problems I mentioned above, it addresses a separate problem, namely the nondeterminism that comes from relying on external repositories that might not always be available. As for the and tags, you didn't address my complaints: (1) if you have to explicitly list every dependency, including indirect ones, doesn't that negate the benefit of maven's transitive dependency management? [Edit: ok, not entirely, because it takes care of downloading the dependencies automatically. But one of the supposed arguments for maven is this: if your project depends on foo, and foo depends on bar and baz, you can just specify foo in the pom, and bar and baz will be pulled in automatically. But that's disingenuous: if you want your build to be deterministic, and of course you do, you still have to specify bar and baz explicitly.] And (2) if you forget to specify a version number for one of the dependencies, doesn't maven just default to the latest version at build time, thus becoming nondeterministic?
Re: Maven builds are an infinite cycle of despair
#45Earlier quoted context omitted.
What you're missing here is sort of described in the RTFM. There are a couple very good, free books on maven that describe this, but in essence: 1) You absolutely should have your own local repository (e.g. Archiva). 2) You should use and tags to force all projects to have the same versions o all deps and plugins. 3) Don't even try using snapshots unless you know what you are doing.
A local repository doesn't address the problems I mentioned above, it addresses a separate problem, namely the nondeterminism that comes from relying on external repositories that might not always be available. As for the and tags, you didn't address my complaints: (1) if you have to explicitly list every dependency, including indirect ones, doesn't that negate the benefit of maven's transitive dependency management?…
... if you forget to specify a version number for one of the dependencies, doesn't maven just default to the latest version at build time, thus becoming nondeterministic?
No.
... if you want your build to be deterministic, and of course you do, you still have to specify bar and baz explicitly
If you declare a dependency on non-snapshot foo, then it will also declare a dependency on non-snapshot bar, ergo, reproducible build.
Your comments seem to be the standard "I don't understand Maven, but I hear that it's broken."
Re: Maven builds are an infinite cycle of despair
#46Earlier quoted context omitted.
A local repository doesn't address the problems I mentioned above, it addresses a separate problem, namely the nondeterminism that comes from relying on external repositories that might not always be available. As for the and tags, you didn't address my complaints: (1) if you have to explicitly list every dependency, including indirect ones, doesn't that negate the benefit of maven's transitive dependency management?…
... if you forget to specify a version number for one of the dependencies, doesn't maven just default to the latest version at build time, thus becoming nondeterministic? No. ... if you want your build to be deterministic, and of course you do, you still have to specify bar and baz explicitly If you declare a dependency on non-snapshot foo, then it will also declare a dependency on non-snapshot bar, ergo, reproducibl…
The original complaint was
> the far more likely scenario is your project depends on a specific version of some other project which in turn depends on the LATEST version of some other project, so you still get hosed even when downstream providers do remember to bump versions!
so are you saying this is impossible (non-snapshot artifacts are somehow forbidden from depending on snapshot artifacts, which is not what was claimed), or that every author has to understand this and package their artifacts perfectly to prevent this from becoming an actual problem?
Re: Maven builds are an infinite cycle of despair
#47> Automatically downloading unresolved dependencies makes your build process nondeterministic! This. You need to be able to check in your build tools, and use them as they were to precisely repeat any build you've ever done, or you're risking bit rot. Ant is sort of painful but it works for this. And if I want my dependencies to be preinstalled rather than checked in and bundled, I'd rather use yum so the rest of the…
This. You need to be able to check in your build tools, and use them as they were to precisely repeat any build you've ever done, or you're risking bit rot. It's not non-deterministic if your dependencies include an explicit version. You should not be using unversioned -SNAPSHOT dependencies for release builds. And if I want my dependencies to be preinstalled rather than checked in and bundled, I'd rather use yum so…
If there's no built-in interoperability, does it become my job to translate my maven dependency on foo:foo:jar:1.2.3 into a spec file dependency on foo-1.2pl3-4.noarch.rpm, and that my maven and rpm repositories each have a package which was built from the same code, and that all foo's dependencies match up in both places (recursively)? How do people actually use this stuff, short of just slopping jars around with rsync and abandoning all automatic management?
Re: Maven builds are an infinite cycle of despair
#48Earlier quoted context omitted.
What you're missing here is sort of described in the RTFM. There are a couple very good, free books on maven that describe this, but in essence: 1) You absolutely should have your own local repository (e.g. Archiva). 2) You should use and tags to force all projects to have the same versions o all deps and plugins. 3) Don't even try using snapshots unless you know what you are doing.
A local repository doesn't address the problems I mentioned above, it addresses a separate problem, namely the nondeterminism that comes from relying on external repositories that might not always be available. As for the and tags, you didn't address my complaints: (1) if you have to explicitly list every dependency, including indirect ones, doesn't that negate the benefit of maven's transitive dependency management?…
Yes it does. A good local repo will cache it. They act as mirrors. Once its cached, and your build is working fine, you can force all your developers to use only your local repo. This solves all non-determinism problems by allowing you to have complete control over all version of all deps and plugins.
Take a look at how to configure settings.xml to force your users to use only your local repo.
As far as tags -- the point of that is to hard-code the version of foo in one spot, like this:
com.example foo 1.1
In child pom, you then have this if you need foo:
com.example foo
And if you use something like Archiva, and force your users through it via settings.xml, then the first time someone downloads foo, Archiva gets it from the web, caches it, all other requests for foo go to Archiva. If foo has a transitive dependency, it will also get fetched from the web one time and cached in Archiva. Thus, guaranteeing that your build is deterministic -- unless you explicitly change foo/bar in Archiva yourself.
Re: Maven builds are an infinite cycle of despair
#49I'm interested if anyone at HN has good things to say about Maven. I've only scratched the surface of it, but my initial impressions have been: * slow (even with -o to stop it downloading the internet every time) * incredibly verbose, in both configuration and output during builds * inflexible (but I've not really looked into plugins or advanced configuration) * opaque and thinly documented even for basic needs I did…
+1 for maven for me. I've used it quite a bit. I've set up (fixed) a lot of really, really bad Ant builds. I have nothing against Ant, but it is easily abused, and can quickly degenerate into a complex mess.
Maven has a learning curve -- although it isn't huge. It can be frustrating sometimes, but if done right, it has so many advantages over other tools. There are free online books on the topic.
Re: Maven builds are an infinite cycle of despair
#50The java build world is perverse. Maven and Ant are imperative, highly limited, domain specific languages using XML for syntax. If that doesn't set off just about every warning bell in your head, consider that Ant performs character set decoding and re-encoding when copying files. By default it will decode every file with your system's default character encoding and then re-encode it with the very same format. As far…
The java build world is perverse. Maven and Ant are imperative, highly limited, domain specific languages using XML for syntax. Maven is declarative, not imperative. Ant is broken in many respects, but your provided example is not true . Ant only attempts re-encoding of a file if you specify text filters (aka variable/string replacement). It shouldn't be a surprise to anyone that string replacement breaks on binary f…
Interesting, thanks for setting me straight, it's good to know that the world is saner than it appeared. I recall some images being corrupted with the copy task in ant and that was the explanation that I received.