Hans is the project lead for a build system called Gradle. He presents it as a step beyond Ant and Maven.

I think he has a point. His system uses Groovy scripts as build scripts instead of XML. The advantages of having a full language available in build [...]]]> Notes from a talk at TheServerSide Java Symposium March 2009

Hans is the project lead for a build system called Gradle. He presents it as a step beyond Ant and Maven.

I think he has a point. His system uses Groovy scripts as build scripts instead of XML. The advantages of having a full language available in build scripts is pretty clear. (Try writing a conditional clause in Ant XML. Ewww!)

Gradle is a build toolkit and collection of small frameworks, rather than one monolithic build framework. It seems to me like this is a step back toward customization and away from “convention over configuration.” But the truth is that one build convention can not serve all build situations, and there’s probably nothing more customized in individual companies than their build, test, production, and deployment environments.

(At MyAds we built a custom version of the Maven Release plug-in just to support our version numbering system. One size does not fit all, especially in building applications.)

Hans says it’s easier to write and use Ant tasks in Gradle than in Maven. Gradle is using dependency management based on Apache Ivy, which I’m not familiar with. He recognizes the value of dependency management as introduced by Maven, so I have a feeling Apache Ivy won’t disappoint. I crave good dependency management, even though it can lead to Maven dependency hell at times. Ivy appears to be leveraging the Maven dependency infrastructure, as well as supporting SVN dependencies.

So I like the concept of using a full dynamic OO language for writing build scripts, especially if the API toolkit is sufficiently intuitive that it doesn’t have a large learning curve. Gradle is worth investigating.

Link to presentation here.

Gradle roadmap here.