Update 2:Stéphane gives an insider's view on our build system. And yes, I am the one that introduced Maven at the beginning of the project, for no particular reason except being caught by the hype, which I quickly regretted...
Update 3: Xavier Hanin, Ivy's creator, reacts on this post and all the coments. His opinion is of course biased, but the essence of it is: there is no single silver bullet, and you need some flexibility. I totally agree.
Update 4: unfortunately, the lively discussion in the comments was lost during a blog engine change :-(
The
Spring project
contemplates moving to Maven 2. I don't know if they really realize what it means and how long their build system will be messy.
We got caught by the Maven hype on my current project, and started using it when the project began back in march. What a mistake! Sure, the verbose
POMs (hey guys, XML has attributes!) allow you to very quickly have simple projects building, but as soon as you want something a bit more complex or specific (because the project
neeeds it), you're lost in the black magic.
I was really happy when the book "
Better builds with Maven" came out as I thought "
Yeah! Maybe I will finally understand how to use this beast". But no, the book was a series of recipes that did not explain the core concepts on which Maven is architected.
So, we ditched Maven on my project, and are now very happy with good old
Ant and the
Ivy dependency manager. A powerful combo that allows us to master our build and add what is needed for the specifics of our project. It is based on a repository (we started with the Maven repo but decided to have our own consistent and always available repository after some bad surprises with the main Maven repo), and it publishes artifacts to the repository as well.
"
Yes, but one of the good things of Maven is to standardize the project structure", some will say. Sure, and that's exactly what we do in our build, with some common Ant files that define all the build chains. Most of the project's build.xml are a one-line import of this common build associated to an
Ivy file describing dependencies and publications. If the Ant project decided to publish some standard ready-made build files using Ivy, the Maven hype would quickly stop.
But where does this Maven hype come from?
Stefano says "
good ideas and bad code build communities faster". That is very true for Maven, which has some nice ideas. People liked the idea of a central distribution repository that avoids copying libraries you depend on again and again in every project, and thus started to use it, especially in the open source community where many projects are libraries or frameworks that depend on other libraries and frameworks. But the implementation of that great idea is so complex to use, that it requires each project that is a bit complex to have some of their developers dedicate time and energy to understanding how to make it work. That drained energy from the using projects to Maven itself, thus creating the hype. If so many people are talking on the Maven lists, there must be something in it, right? And there are so many libraries in the artifact repository, so why not use it? And you've got a snowball effect that explains the hype.
But as I said above, using Maven drains time and energy from the using project's contributor and can place complex projects in very critical situations. Switching the build to Maven 2 has endangered
Cocoon, with the main development branch being un-buildable for
months, except by a few that spent so much energy on this that they now know the internals of Maven as well as those of Cocoon. And the docs now say that building Cocoon "
can take from 5 minutes to maybe 4 hours"!!!
So, Spring folks, think twice: what do your users want? A Maven-based build? No. What they want is the Spring build to create artifacts that are published in a repository with a proper description of dependencies. No need to break everything for that: keep your
Ant build and add a bit of
Ivy!