I had the pleasure of chatting to Jon Tirsén last night. Amongst one of the many topics we discussed, was his Ruby-based Continuous integration build tool “DamageControl”:http://damagecontrol.codehaus.org/builds/damagecontrol/docs/index.html. Designed as the replacement for “CruiseControl”:http://cruisecontrol.sourceforge.net/, DamageControl offers much more flexible framework, and has been running the “codehaus”:http://www.coudehaus.org builds for some time now.

“Continuous Integration(Continuous Integration by Martin Fowler and Matthew Foemmel)”:http://www.martinfowler.com/articles/continuousIntegration.html is the development practise whereby each CVS checkin results in the code being built and tested automatically – in this way encouraging frequent checkins and resulting in people having the most up to date code, and reduces integration issues.

After asking how development DamageControl was going, it turns out that Jon is looking to re-implement it in Groovy. Given that Jon seems to be such a fan of Ruby (I’ll stop short of saying ‘zealot’ as I don’t know him that well) this was a surprising admission. The main reason cited was that Java-based programs have nicer deployment mechanisms than Ruby’s (or most scripting languages) text files. Personally, the reason seems to have a lot more to do with the current mind share of groovy, and the fact it is based on a far more popular platform, in the form of Java.

A Continuous Integration tool is (potentially) such an important part of an Agile development methodology, that a well-maintained, flexible tool is very important. By basing it on the Java platform the number of developers available to help develop and maintain a system must surely outweigh the number of Ruby developers out there. Also the fact that the majority of agile development itself is done using Java, means that those companies using a Java-DamageControl are more likely to have the expertise in-house to administer, support and extend the program, and would therefore be more willing to use it. I would also hazard a guess that movement from Ruby->groovy, with groovy’s Ruby-like features would be much less work that a move from Ruby->Java language.

We also briefly discussed the recent “Groovy JSR(JSR 241: The Groovy Programming Language)”:http://www.jcp.org/en/jsr/detail?id=241, and agreed that the important point wasn’t that it was groovy itself that was being submitted, but that another language based on the Java platform was being submitted. .net has stolen a march on Java, basing multiple languages on its common-runtime (C#, VB, J# etc). Java is just as suited to this kind of approach as .net, and it is time we started seeing Java as a platform rather than a language. This is certainly something MS has achieved quite well (in marketing terms if nothing else) and is definitely something Sun et al can learn from. Hopefully we’ll start to see other languages being submitted to the JSR in this way – I just hope that they won’t have to have the backing of big name companies to achieve this (groovy is backed by the Apache Software Foundation, BEA and ThoughtWorks).