Groovy Ant Builder

The other day, I was tasked to modify a Java web application. However, after checking out the source code from CVS, I found no build script. It looks like I'm expected to use WSAD to compile and package the application. This is a direct hit in my one of my software development principle: Never rely on an IDE to build an application. Anybody should be able to check out the code and build it with some non-GUI build tool.

The client already use Maven for other projects. However, the application I needed to modify did not have the Maven standard directory layout. The CVS repository also contains the library this application depends on. Because of firewall restrictions, it is not easy to use Maven dependency management (jar download are not permitted by the proxy). They run their own Maven repository but adding stuff in it is no easy task.

The easiest solution to quickly get the job done, would have to create an Ant build script. However, I did not have Ant installed and the proxy would not allow me to download it.

I did have Groovy installed on my portable hard-drive. Since Groovy comes bundled with Ant jars and the Groovy Ant Builder, this was now the fastest path to creating my build script.

And it fact, it was quite easy to get the job done. Task are easily defined and the builder syntax remove all the pain of XML build script. Here is an example of my compile task :

void compile() {

ant.mkdir(dir: "${classes_dir}")
ant.javac(destdir: "${classes_dir}",

srcdir: "${src_dir}",
classpath: "${compile_classpath}",
target: "1.4",
source: "1.4"
)

ant.copy(todir: "${classes_dir}") {

fileset(dir: "${src_dir}") {

exclude(name: "**/*.java")

}

}

}

The thing that seams to be missing is the proper declaration of task dependencies. It seems that the only way to do dependencies is to call another task from a task :

void war() {

compile()
ant.mkdir(dir: "${dist_dir}")
...

}

This seems a bit backward. And I don't know if dependencies will be called many time if they are referenced my many tasks (I will have to test it).

I did consider using Raven, but right now, it lack customization when you want to exclude stuff from the build or if you do not want to use dependencies (but prefer to specify your own compilation classpath).

I also looked at Gant but did not use it for two reason. First, I was not able to download it (proxy restriction) and second, for some reason, when I look at their example, I find them a bit ugly and it seems that you have two ways of doing stuff.

For my particular problem, Groovy Ant Builder allowed me to get the job done quickly and easily. It reminded of things I dislike about Groovy syntax like have to use def to define variable (but not to define methods) and having to specify void as a return type when my methods does not return anything. I much prefer Ruby syntax.

2007 Predictions

Everybody doing it! Not wanting to be left in the cold, I will follow the herd and make predictions for 2007.

RoR will run flawlessly on a Java Application Server

The good people from JRuby are making incredible progress since they've been hired by Sun. We will soon be able to run RoR applications with no (or very little and trivial) modifications on Glassfish or other Web Container. Will that makes RoR application more scalable? I'm not sure. But it will increase RoR momentum in Java shops. When you talk about RoR to a java shop, the first question they have is "Will it run on Tomcat|WebLogic|WhebSphere|...?"

JRuby will take the top spot for scripting the Java platform

To the demise of Groovy, JRuby will take the spotlight. The main reason is the previous prediction. Once you can run RoR on a Java application server, nobody will need Grails. Grails is the only use of Groovy that create adoption.... Unless some other killer Groovy application, tool or framework is created.

RoR adoption continue

That's a fairly conservative prediction. RoR as a lot of momentum.

Java 6 adoption will start slowly in Q3

While Java 6 is out. It's adoption will grow slowly and will mainly be driven the scripting language support. Java 5 had many compelling reason to get adopted by many shops, but many many many application are still running on Java 1.4. Beside scripting support, there is nothing compelling enough in Java 6 to make it's adoption within the enterprise faster that Java 5.

Something will happen in Java build tool space

A lot of people are tired of Ant . Maven is cool, but lacks flexibility. Scripting language is getting more attention... We have Gant, Raven, JRake and many other existing or yet to be created build tool that use scripting language. By the end of the year, one of them will start getting a lot of traction. My best guess for now is Raven.

Java Specification Requests will become less and less relevant

The JCP is not working very well. It's too lengthy. Design by comity does not work well. Many JSR do not stand the sand of time. Today JSR mostly reflect some existing API with less feature (JPA vs Hibernate for example). They do not offer innovation, they just tend to seal mature innovative technology in the platform. New language features takes too long to traverse the JCP and with the open sourcing of Java, it will become easier for one group to add new feature to the language and to make a Java distribution of it's own. And with JSR like JSR-277 that create more turmoil than solve any problem, more and more people loose interest and faith in the process. Sun is not even interested in really supporting existing JSRs. We have a JSR for Groovy, but Sun hire the JRuby developers without giving any resource to Groovy. That's it! I made my prediction for 2007. This is probably my last post of the year, I will try to post a bit more often next year! In the mean time, have a Great Christmas and a really Happy New Year!