It’s time to write a better build tool
That’s what I’ve heard more than one time in the last months, half of my friends complain about maven, the other half is just almost happy with ant. The rubists are generally happy with rake, the biggest problems are on the java/.net world.
So I thought about branching ant and rewriting it in a slightly different way, using yaml instead of xml and having always only one option for any task parameter. I always hated and found difficult to remember how to do things in ant since there are always two or more good alternatives (like why there’s a dir and a file parameter option in the delete command? Isn’t a directory a file?).
So, I don’t think I’ll be able to allocate a lot of time to this, but I would love to hear something from you, ideas and comments.
In the last weeks I’ve started to write a shared mind map with Staffan Nöteberg on micro time boxing… Maybe we can do the same with this topic.
Ping me if you’re interested.
Oh and we also realised we could roll new some tasks in ruby (say to use rsync or do system-level deployment tasks) and they would be indistinguishable from java tasks in terms of the build tasks.
But then a shiny thing happened and I forget what happened after that.
I did a post on the characteristics of a good build tool which may interest you
http://jupitermoonbeam.blogspot.com/2008/08/product-based-build.html
+1
Gonna ping you in a weeks time or so.
I would highly encourage you to focus on running rake under JRuby and making Ant tasks dead easy to use.
Though given that it’s whitespace-sensitive, YAML would be awesome for irony. “… is a YAML-based build tool. In theory, it is kind of like Ant, but without Ant’s wrinkles.”
[...] post about the need of a new build tool had many comments and reactions so I started, before coding something brand new, to search on the [...]
Hey Toni!
Yes please. I explored this a couple of years ago with Dante Briones (ex-TWer). Where we got to was:
Ant is three things:
1. It is a way of expressing intent, namely build rules and dependencies. It uses XML. XML is ugly.
2. It is a dependency resolver. It works out that if A depends on B and C, and C depends on B, then it should run B, C and A in that order.
3. It is a library of useful tasks. It has tasks for everything – compile, test, coverage (emma, cobertura), assemble jars, wars, ears, deploy to any number of J2EE containers. Bucketloads of really useful tasks.
We decided ruby would be a much nicer way of expressing 1 (or yaml, but ruby means you can have basic branching and looping, and methods if you like). We implemented 2 in about ten lines of ruby code. We worked out if we used JRuby we could use all the existing Ant tasks, parsing the default.properties files out of the task jar files.
The tricky bits were and matchers. Dante got filesets working but I don’t know what happened to the code. It wasn’t that hard though.
Anyway, I think there’s definitely a gap there and I’d love to see something in (j)ruby that could use all the existing Ant tasks.