Panning the whirling RSS feeds for nuggets of gold, I came across something I had almost given up on finding: a build tool that I could imagine giving up Ant for. Now I’m an Ant fan from way back, having used it In Anger as far back as 1999. I’ve heard the pitches for Maven, and have been sympathetic, but never made the jump. It always seemed like something that was good in theory, but which scared me in practice. The mixed praises and pans that Maven earned from the Massed Mind of the web seemed to cement that opinion, and in spite of some extremely trusted colleagues backing it, I never managed to pull the trigger. At this point, I’m not sure I will, now that I’ve stumbled across Gradle

Gradle, as the name might suggest, is a Groovy-based tool, defining a simple but powerful DSL (domain specific language) for builds. Now that doesn’t sound like much. Every build system has defined a small DSL, going all the way back to the chthonian depths of Make. But Gradle doesn’t just define a DSL, it defines a Groovy DSL. That makes all the difference.

For those who haven’t encountered them, it’s tough to describe just how mind-alteringly cool Groovy DSLs are. Using some very clever punning around its closure syntax, Groovy allows you to build domain specific languages which can be embedded in otherwise vanilla Groovy code, and which can in turn have Groovy fragments embedded in them. This is incredibly powerful, allowing exactly the sort of promiscuous mixing of declarative and procedural code that a full-featured build system needs. Groovy DSLs are all, as a mere fact of their existence, Turing complete and able to call upon the full majesty of the Java ecosystem. They also, again as the merest side-effect of how they are constructed, are able to embed arbitrary DSL code-generation functionality within them, making every Groovy DSL trivially field-extensible. None of that costs anything to the DSL user, and hardly anything to the DSL creator. It just works. Groovy itself is a very nice scripting language, and well worth learning. Groovy DSLs have potential to be a disruptive technology, blurring the code/data distinction in some extremely powerful ways. (Now if only someone could figure out a good way of documenting them.)

Extremely full-featured, declarative dependency structure: Dependencies are declaratively specified as part of the project DSL, and fetched using Ivy as the engine. Works with Ivy or Maven repositories, simple checked-in lib directories, and a bunch of other repository structures.

High-quality and simple multi-module project support: Project modularization is declaratively specified via the project DSL. Sub-projects can optionally have their own Gradle build files which inherit in interesting ways from the parent project, but they mostly don’t need to.

Configuration via convention: Like Maven, lovingly chosen defaults, cleanly overridable. Unlike Maven, the conventions are defined via plugins. The core system knows nothing of them, buying you a degree of independence from build system changes.

Familiar, Turing-complete, non-XML script definitions. Scripts are written in Groovy, with all the power that implies. Ant tasks are available via Groovy’s built-in (and desperately cool) AntBuilder.

Highly extensible and abstractable. Ant’s extension capabilities ranged from sucktastic in the initial release (no extension other than painfully written and atrociously deployed Java tasks), to merely half-assed by 1.6 (horrid and non-standard macros that were only marginally better than cut-and-paste). Extension in Gradle is via defining methods and classes in Groovy, which looks just like Java but shorter. You can either define them inline, or put them in libraries, your call.

…while keeping Ant’s biggest strengths

Humility. Ant always understood that a competent build master will end up automating more sorts of things than the developers of Ant had ever thought of. Just yesterday I had to automate six different quite complex processes for creating test Derby databases for my Day Job project. Ant made that easy, in spite it being well outside the conventional concept of “build”. Creating new sorts of functionality is an in-line activity in Gradle, as it is in Ant. Creating inline tasks is actually easier in Gradle than in Ant, as they can be written in Groovy, rather than in Ant’s exceedingly weak XML-based scripting language. Maven, OTOH, mostly requires plugins to be created and deployed if you ever wish to do a task no-one else has contemplated, raising the cost of quick scripting greatly.

Minimal buy-in. Ant never required that you change your code structure before you started using it. The build was subservient to the code, rather than vice versa. This made it very easy to get Ant working without annoying team-mates who (lamentably) couldn’t care less about the build. The thing the Maven folk never seemed to realize is that just about every project that converted to Ant early on did so by stealth. It’s sad that this made a big difference, but such is the way of this fallen world.

Platform independence. It’s Groovy, which is to say it’s the JVM. Move a build script from my fuel-injected dual-overhead-cam cherry-red MacBook Pro to whatever damn $3.62 Linux partition that Ops rented from some retired Mah Jhong hustler in a back alley of Shenzhen, and it All Still Works. That probably doesn’t mean much to you whippersnappers, but to us oldsters who lost hours tracking down places where Make didn’t like some damn backslash, it’s worth mentioning.

Put together, that positions Gradle nicely as “a better Ant”, which is something that Maven, for all of it’s strengths, simply can’t be described as. With Ant development seemingly moribund after 1.7, there’s a lot of potential in being “a better Ant”. It’s still early days (they are calling the current release 0.2), but I’m definitely putting Gradle on my “technologies to watch” list.