Spring switching to Maven 2…riiiiiiight
The first reaction when I read this was:
Another good piece of software that will lose thousand of hours in build problems.
Why ? because it will go through the same hurdles that large projects such as Apache Directory Server or Apache Geronimo go through just about every day.
Sylvain points at the Cocoon instructions and the most revealing part is actually:
To build Cocoon, use the following command:
$ mvn -Dmaven.test.skip=true install
In case of any failures, repeat command as necessary till you see the message:
BUILD SUCCESSFUL
which is not a joke and one of the most dramatic aspect of Maven. It is unreliable and unreproductible.
Sylvain already blogged about it extensively and revealed the fact that we are using Ivy to manage our dependencies (which at this time are in the 3-digit figure). A project is indeed only a matter of importing a one-liner build.xml, declaring a name, a version, a package information (for manifest purposes) and ivy.xml.
Interestingly the most annoying elements at this time are due to the extra layer of compatibility with Maven that I needed to insert to offer a painless transition a few months ago. This is something I plan to get rid of very soon now that we are mostly in cruise control mode for this build and I start to see patterns emerging and needs showing up.
Early on, when Maven was initially taken (for no reason at all actually) I spent a lot of time actually getting the dependencies from a reliable source (ie: not ibiblio or whatever but direct from the website). Figuring out the dependencies, rewriting the POM. Anything you get from an online repository is inherently badly written – should it be if it is written by a Maven user that just wanted it on the repo or by the developpers of the module themselves who don’t really know how to write a POM either (there’s no valuable documentation on it, it is extra-verbose as XML attributes seem not to exist in Maven XML land so people tend to get lost and not really update valuable information and/or totally useless information get into the repository)
To describe partly the current build system and without saying too much. I have roughly 2 build files, one being from a normal application that produces a jar, and another one for a web application that imports the ‘normal application’ one and that overrides one target (and define a few others webapp related), a web application producing both a jar and a war.
- A project has therefore just to import either the normal or the web application one. A one-liner. I provide typical templates to use for build.xml, build.properties and ivy.xml, the later having predefined configuration and a set of dependencies to use de-facto (for example servlet-2.4 in compile configuration for webapps, etc…)
- As of now each project is also publishing its sources and javadocs.
- The whole set of application is described using a ‘virtual ivy’ file (no artifacts) which allow to have a graph/report of dependencies or build them (I have another build for that which basically does subant calls)
- It is built using an Ivy build list that determines the order of dependencies.
- I have a few niceties, like for example I have added a target ‘whoami’ which just print out the name of the project using an <echo> this way you can know easily what is the order of the whole build without actually building it. Seems stupid but it is pretty helpful sometimes.
- It is of course doing the whole unit test she-bang on request and gives coverage information.
- For webapp, it launch a pluggable servlet container against your war in remote debug mode as a default.
I’m still not satisfied (and people who know me also know that I’m never satisfied) of the current state of affairs and things could be even better and simpler in many many ways.
I just want to make that build simple and reliable. I don’t want it to be a whole kitchen sink that does everything (and nothing), therefore I’m being very careful not to add too many features that people would want (most of the time they just prove themselves unneeded). I first want to make it build in a very predictable way, if something fails, I want to know where it fails and why…and as early as possible (without again writing a truckload of code, properties, conditions, …). This is basically THE goal. It should not make coffee, we have a couple of coffee machines for that. 
)
And for any large build, believe me, you don’t want to have something too smart.
The most difficult thing is to actually cater to different styles and anticipate also the way it evolves and/or control it. A codebase normally goes through a lot of changes in the initial phase, the versioning is also much simpler while this tends to evolve with time to components having their own versioning, branch, tags and stabilize. And it stabilizes only if you are able to control the growth phase.
That said, I’m looking forward to the next release of Ivy 1.4 and Ant 1.7.0 to simplify things even further.
There are a couple of things that can however be improved on Ivy but I will keep that to another post.
As for Spring Framework, let’s just hope that Spring does not turn into Fall.
But good luck guys because you will need it.
My other area where I would like to focus afterwards will be integration and deployment and I think my dear friend Steve has a couple of things I want
Oh and btw, Steve is also finishing the 2nd edition of Java Development with Ant (aka jdwa) published at Manning. Believe me you don’t want to miss that one when it will go out and I expect it to have as much success as the very first version. It is satisfying sometimes to know that quantity is synomous of quality.
