Wednesday, October 8, 2008

Ant vs Maven, Episode 2 : Gant or Gradle?

[Editor's note, 2020: those interested in former Codehaus projects may be interested in this link.]

In June, I gave a tech talk on Gant. Gant is a Groovy layer on top of Ant -- essentially Groovy's AntBuilder on sterioids. My thesis was:

  • We are in a post-Ant world, and at a crossroads. One road involves continuous integration tools such as Hudson. Another road concerns project framework builds such as Maven. A final road is for general purpose build tools such as Ant. These roads may intertwine, and even build on one another.
  • However, with respect to the latter road: we need a new general purpose build tool. We owe a tremendous debt to Ant, and it is still useful, but it has serious problems. First, XML is not a programming language. Second, the Ant community can't decide if it is declarative or imperative: e.g. properties are immutable, except when they aren't. Finally, some of Ant's built-in tasks (e.g. javac) are great: call them "big iron" workhorses; however, the act of "machining" a new task is prohibitively difficult.
  • Enter Gant: it rests on top of the "big iron" tasks of Ant, but allows us to work with a real programming language (Groovy) so that simple logic is trivial and new tasks are like working with modelling clay. Put another way, if Ant is a rigid, metal clock, then Gant is weirdly fluid -- yet both keep time.
That was June. Now, alas, it isn't so simple: Gant has had a competitor named Gradle. Gradle is more 'heavyweight' than Gant: it uses a full Directed Acyclic Graph (DAG) and aspires to be closer to something like Maven or SCons. In terms of formal build theory, Gradle is more powerful than Gant. The question, posed on the Groovy mailing list, is how to unify the forces. It is a fascinating debate, and rather important to the Groovy community. I haven't used Gradle so I can't choose, but I will say that I think this direction is the future for build tools: dynamic languages are a great fit for builds. Here is a quick (hopefully correct) rundown:
  • Gant rests on top of Ant. It is lightweight and is used as a task management framework in Grails (quite a pedigree there).
  • Gradle has strong Ant integration, but aspires to be more than a scripting language for Ant. It has DAG support and targets a space closer to, and actually beyond, Maven.
  • In simple terms, Gant is analogous to Ant ; Gradle is analogous to Maven. And so many of the usual arguments apply. However, an open question is if Gradle can serve Gant's position as a lightweight tool (where lightweight itself is open to definition).
If you want to be on the bleeding edge, check out this debate. I'm happy to see that the discussion is civil and intelligent: these are cool blokes. Very interesting.

4 comments:

Anonymous said...

Have you taken a look at scons? I've been doing some development in c++ recently (I mostly do java at work) and was really impressed with its abilities, especially since it allows for easy scripting in python - something that ant's xml syntax has always been lacking.

It isn't as mature it terms of filesets, paths, and additional deployment tasks like ssh/sftp, but it would be nice to have a singular build tool that could be useful across all languages.

Admin.Mediocre-Ninja said...

The more, the merrier !

You're right , let's order pizza and watch !

Michael Easter said...

@ kushaura. I haven't used scons but I am a big Python fan so it has sounded interesting to me.

I hear what you are saying about a singular build tool but that harkens back to Make, which scares me. I think it useful to have a tool that is on the same platform (e.g. JVM) as the project.

@ ninja. :-)

Anonymous said...

I believe you are correct - we are at a crossroads. Many open source projects seem to be switching or at least adding Maven. But the enterprise developers I talk to who use Maven are generally unimpressed. I use Ant myself, and am more than ready to ditch the XML. Out of the dynamic language build tools I personally am most intrigued by Gradle and plan to give it a try.

I found it interesting that you mentioned Hudson / Continuous Integration Servers as part of the crossroads, whereas I view it as orthogonal (unrelated). Whatever CI server you use needs to support the build tool you use, but otherwise they address different domains.