« Junit 4 | Main | Get Your Messaging On »

Heart of darkness: what's wrong with Ant


What I didn't see on the MARC list was a lot of postings by java folks who were very experienced with Ant and have decided that Ant just doesn't cut it anymore because of reason X, Y or Z. So what I'm really looking for are well laid out arguments for why Ant is really so terrible, and why something else is better because it is simpler, more productive and/or more powerful.


  • Ant encourages duplication across build files. Duplication is built into Ant insofar as you will always be fighting with it if you want to say something in only one place. Make let you normalize just about everything, because it allowed you to import between files. Ant is currently stuck with entity inclusions - but 1.6 is supplying an import function.

  • Ant isn't recursive. A build system that is going to scale with a codebase has to be recursive. Period. When people are going on about dealing with subprojects, or about standard project and directory layouts, really what they are talking about is the need for recursively enumerable build structures. If your subprojects have the same structure as the superprojects you can use the same scripts to build them all, and you can reorganize stuff more easily.

  • As bad as the lack of recursion is, its worst side effect is crucifying - Ant's enforcing of downward dependencies. When you create a subproject, you should not have to declare its subtargets at the top level - the build process should descend and execute against the subtarget automatically so that the subproject will simply inherit the master's targets. The job of the subproject is to declare specific dependencies and parameters to the key targets (this is roughly how a decent make setup works, and maven seems intent on working this way as well). It's important to be able to keep adding targets and projects without changing the master build targets - if anyone suggested that the way to add a subclass to an inheritence hierarchy was to first declare it in the base class, they'd be laughed at. But this is how Ant works today. [Junit also has this problem with its test suites.]

  • Ant doesn't understand dependencies. I'm well aware of the "it's not an expert system/ dependency checker" arguments - they're absolutely true. But that's moot if what you need to build software is in fact an expert system or a dependency checker. Asking the buildfile writer to explicitly manage inter-project dependencies was never a good idea, unless you intend to only have one project.

Which leads us onto maven. The main objection to maven is that it's a patch around deficiencies in Ant. Every time I use maven it feels like there's something inherently wrong with it. It's building on the wrong kernel for the job, much like NT did with DOS, which has the effect of making it something of a stovepipe system. Despite the amount of effort that has gone into maven to help you with Ant (and you should dig into the source to see what I'm talking about) it remains 16 bit Ant at the core, the limitations of which just can't be abstracted away that easily.

In any case, correct me if I'm wrong here, but I'd say the Ant vs Make debate is pretty much solved. Is there any one out there who has uses both Ant and Make enough to make a rational comparison, and has gone back to Make because it work better?

I've seriously considered it, yes. Many times. I think you need to have seen a good makefile setup to appreciate why Ant is not make without make's wrinkles. Ant is nothing like make. That, or hacked at an expert system at some point. Unfortunately good makefiles are rare and most of us don't hack expert systems. The Ant vs make debate may be solved, insofar as there's no point arguing for make anymore. That's not to say that Ant doesn't bring its own issues to the table.

The reason I haven't moved back to make is social not technical. Ant has two characteristics to which I'm highly sympathetic - worse is better, and view source. It's far, far, easier to get folks to first accept, then use, then extend, Ant, than it is to get them to use make - make is freakish by comparison.

I've been pretty hard on a tool I use every day and have encouraged others to use: I am despite the post, a strong Ant advocate and have no problem blowing Ant's trumpet to colleagues or clients. When it comes to Java, nothing much happens for me without Ant and Junit. But I don't think Ant when it was conceived, was ever designed to handle the complex setups it is used for today. It's very much a victim of its own success, which can be attributed to its worse is better and view source qualities - Ant is a user friendly technology. But an important thing in advocacy is not to pretend there are no problems. I think there's a good argument to be had about making Ant a better build tool, but remain dubious that maven is the way to do it.

[alex reece: acid lab]

October 4, 2003 12:58 PM


(October 6, 2003 05:49 AM #)

Absolutely! Anyone who has worked with elegant makefiles (using GNU make, esp.) will realise the serious deficiencies of Ant. However, I continue to use Ant for java projects because I really have no choice - the java ecosystem is so tightly integrated with Ant these days that there's no more point in waging a lone battle and going with a different tool.

There's one other point I would like to address from the original blog of Patrick. If someone hasn't played with make at all, how does it qualify him to compare it with Ant and declare the latter as the winner. Seems pretty in-line though with the phenomenon of java programmers who've never programmed in traditional languages like C/C++ or scriting languages like Perl and with absolutely no experience if the classical UNIX tradition of programming making statments on the superiority of java and worse, j2ee!

Bill de hra
(October 6, 2003 10:47 PM #)

Prasad, I wouldn't be so hard on Patrick, I think it's an understandable reaction. Like I said, make can seem a bit freakish, all the more so if you've been brought up on Java+XML. But I think anyone who is using Ant heavily or is a build maintainer should take a look at make - it's the latin of build tools.

Curt Hagenlocher
(January 5, 2004 03:47 AM #)

FYI, Windows NT was not in any way built on top of DOS (though Windows 3, 3.1, 3.11, 95, 98 and Me were).

(January 5, 2004 06:22 AM #)

The biggest problem with Ant that I've seen is simply that the best practices are not commonly known or understood. Experienced Make users, try to use it like make. A very serious mistake. Java programmers want it to be like Java.

I've managed massive (700KLOC) projects with Ant. The build included 4 code generators, sub projects (persistence, domain, common, gui, tools), unit-test targets, functional test targets, and packaging of a EAR with 50+ EJB's (just to name a few features). The whole build consisted of about 1000 lines of XML. Any attempts to do this with Make in fewer LOC would be humorous.

Maven attempts to create best practices for build files, unfortunately it comes in the form of a clunky, constraining, overly complex tool.

It's true that the xml syntax of Ant is not particularly elegant, but I like the declarative syntax. Builds consist mainly of properties, so at least XML attributes provide a clean, simple way to define elements. Groovy already provides support for replacing Ant with a full featured, more syntaciclly clean implementation. However, it doesn't create a set of best practices for builds. People will still create crappy builds. Maven is not the answer for this. It does not scale. Complex projects need customized build scripts. In the end, you will fight Maven till its bitter end.

Randy McLaughlin
(January 29, 2004 05:12 PM #)

I've just today discovered that there is a "what is wrong with Ant" dialogue going on and I'm pleased to find that I'm not alone. My main issue has been with the noisy and cumbersome syntax dictated by the use of XML. From this journal I learn that there are far more complaints (my experience with using Ant is rather shallow).

I've been starting to work on a project to replace the XML-based syntax of Ant with one based upon ILD [http://www.outerp.org/ild.html]. My idea was to build this as a demonstration project for my Outerp [http://www.outerp.org/] project.

A simple Ant buildfile written in ILD might look like:
project iant
 default hello
 basedir ..
 target hello
   echo hello world!

or, if you don't like the leading whitespace, it could look like:
#@indentation char-indent .
.project iant
..default hello
..basedir ..
..target hello
...echo hello world!

or like:
#@indentation numbered
1 project iant
2 default hello
2 basedir ..
2 target hello
3 echo hello world!

But what I'm now learning is that there are other problems with Ant. Maybe there is more need out there than I thought and maybe there is need for something more comprehensive than simply a file format replacement.

Trackback Pings

TrackBack URL for this entry:

Listed below are links to weblogs that reference Heart of darkness: what's wrong with Ant:

» Why Bill de hra doesn't like Ant from Stefan Bodewig
Interesting blogs on build systems these days. I found Bill's list of what's wrong with Ant via Bruce Eckel's Feedback Wiki. Most of Bill's points seem to be addressed with 1.6. "Ant encourages duplication across build files." As he already not [Read More]

Tracked on January 8, 2004 01:59 PM