Alef Arendsen ponders on whether to switch from Ant to a Ruby build tool. At Lecando we just this week finished migrating away from a Ruby based build system we called Raven. Our former employee HÃ¥kan speaks in his blog entry from way back then about the enthusiasm we shared. Of course, HÃ¥kan speaks of our migration from Maven, the build tool from hell of which one should not speak.
So we’ve now gone full circle - Ant - Maven - Raven - Ant. So what happened and why?
Our build.xml used to be a trillion lines long and quite unmaintainable. When we first saw Maven we thought “Easy targets due to standard directory organization, automatic dependency downloads and we will probably read that really nice webpage thingy very often. Way cool, we want that”. Since we never have hesitated to throw new fun explosive stuff onto our e-learning fire we pushed all our directories around, picked up the ball and ran with it.
I looked at our old project.xml file today. Man, that thing is ugly. As Cedric points out, Maven is really four languages, and Jelly is one of them. Ouch.
At that time we were bitten by the Ruby bug due to a number of reasons, two of them being Jon, head chef of Damage Control who had just left us for new frontiers, and Anders Bengtsson who used to work for us but is still a good friend of some of the guys. This combined with our craving for a shiny new build system made us roll up our sleeves and start to build our own build system in Ruby, Raven.
When you start to build a new file system you most probably start with the easy pieces. “Let’s see … compile? That’s good - we need to compile in our projects. And we can set our classpath in a really non-obtrusive way. Oh, this feels so good, I’m glad we’re doing this. And next … Test? Awesome, we’ll be done in no time.”
… A little later …
“OK. it is not a good as in the beginning but we’ll refactor it. Now we just need to build the docbook docs, package the war, pack it up in a ear, zip that up with all external docs and whatnots and we’re done.”
Spoiler: The resulting build was as hard to maintain as the previous ones had been, albeit in a prettier syntax.
I believe it is exactly the same thing as when you start out with your Ant build file. As long as you’re setting up the compile and test part everything is really clean, but when you get into the specifics that is needed for your app like for example signing an applet - we used to do that - things get dirty. And it does not matter what language you do it in, it is complicated even in plain English, or Swedish. (”Take those files and sign them with that certificate file over there to produce an applet as a jar for Netscape, and when your done you take the same files and sign them again, but this time with that certificate file over there for Explorer, and, oh yeah, make it a CAB file. Don’t mess up or the browser barfs”)
While we were doing this, things happened in Ant land. Imports and Macrodefs solved a lot of problems, making build files readable. IDEA even provides code completion and refactoring support for Ant. As you might suspect, we did not have that for Raven. We slowly accepted fate and began the walk back into XML. However, among the brackets are a few goodies in addition to the ones above.
Ants platform independency is king. Visar, our designer guy, can run the app from his Windows box as well as we do on our Linux ones. I know, Ruby is supposed to be platform independent, but unfortunately it works in the same way Python does it - almost.
We have even rolled our own CruiseControl in Ruby. We really did not like CruiseControl two years ago so we might not use it now either, but at least now we have the choice. I’ve read a lot of good things about it recently and if it is good enough for Mike Clark it must be good enough for us as well.
To sum it up, Ant is a standard which in itself might not be the best thing at all, but with all the support for it it certainly comes out on top for us.
