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.
- 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).
5 comments:
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.
The more, the merrier !
You're right , let's order pizza and watch !
@ 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. :-)
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.
Greeat post thanks
Post a Comment