Java and the Build Process
On Wednesday evening I attended my first London Java Community meeting, the subject of which was the build process. We had a presentation on Ant, Antelope, Maven, Gant and Hudson. After the presentations was a free form discussion about various technologies, when they are appropriate to use, their benefits/short comings, etc.
The presentations were short (around 15 minutes for each topic) although the evening as a whole gave me the oppertunity to think about the build process (an area I have had a fair amount of experience in) and really to appreciate its importance.
Although each of the technologies were impressive, on my current project a lot of time and effort has been invested in creating a build process using Ant. Although it may not be perfect, it does a great job and I think it would be fairly impossible to give a good enough reason why investing time in to moving to a new technology (such as Maven) would be of significant beneft to the project…and to be honest, I don’t think I could make that case.
Sometimes when someone recommends a technology, the underlying reason for why a particular person perfers it is that they might prefer the syntax (for example a person who hates XML would surely choose Gant as a preference over Ant), but that alone is not a good enough reason as to why time and effort should be invested in the move.
I guess ultimately, if a certain technology will save you significant developer time during day to day development activites, then surely it has to be a good move. But if this is overshadowed by the cost of making the move, training developers to use the new technology and increased maintenence time due to lack of familiarality with the software, then the move isn’t going happen.
Regardless, I certainly enjoyed the oppertunity to learn about the other technologies that are out there and will keep them in mind for the future if I’m ever in a position to choose what would be used on a new project.
Get the tools and processes right at the beginning and the rest will be a piece of pi…
This talk was my first at the java users group also, and I too found it really useful to spend an hour thinking about build processes away from the particular project that takes my 8+ paid hours per day.
I agree that when the underlying motivation for change is just someones personal preference (ie dislike for XML sytax) then the expected benefits from changing either the tool or the process cannot be that great.
There can be some unexpected benefits though when trying a different tool. On one recent project we shifted from using a highly modular ant build to one using maven2, simply because we wanted to cut down on the amount of build code we had to maintain. What came as a slight suprise (and perhaps shouldnt have been) was that because maven2 is inheritently big on declarative versioning, we felt compelled to take a closer look at our own versioning efforts, and realised there was room for improvement.
Perhaps the lesson for me was that even though decisions on build tools and processes usually get made upfront at the start of a project, it helps to revisit those decisions from time to time, even if it costs a little time/efffort.
Hey Ross, thanks for the comment!
Since I wrote the post I’ve started on a new project and we’ve gone down the Maven2 route. I’ve not had that much exposure to it yet as were busy doing design work but I have to say that I’m impressed with what I’ve seen so far!
Having given more thought to the subject I think what people probably like more about Ant is that it is the least prescriptive of the two, you can pretty much do whatever you want with it. But certainly, there’s a hell of a lot less crap to maintain with Maven2!