Apache Ant

Ant (http://ant.apache.org/) is a Java-based build tool. In theory, it is kind of like Make, but without Make's wrinkles.

Ant is the de-facto standard build tool for Java projects. It was originally written in 1999/2000 for enabling Sun's code donation of the JSP engine that became ApacheTomcat to build on multiple systems, spread across the Apache projects and into the world at large. Integrated into all mainstream Java IDEs, it helps reduce friction between IDEs. Developers can use their favorite IDE; all can use Ant to build. It is probably far more ubiquitous now than the product for which it was written.

Single-step debugging of ApacheAnt scripts is supported in EclipseIde and NetBeans IDE. (But not IntellijIdea.) See DebuggingAntScripts.

Ant Libraries:


ApacheMaven is an alternative tool which may scale better.

SconsBuildTool claims to be a build tool without NantTool and ApacheAnt sinkholes.

See also AntVsMake discussion for commentary on some of the strengths and weaknesses of the Java ant tool.

(See also ApacheMaven, PerforceJam, SconsBuildTool, MicrosoftBuild and ApacheAnt's hillbilly cousin NantTool.)


Ant is written in Java and you describe what you want Ant to do using XML. Compared to traditional 'make' the description is higher-level, less tied to OS-dependent shell and command quirks, which makes it a (relatively) true cross platform tool. The two main concepts in Ant are targets and tasks, instead of going a long way using many words (which you could find at http://ant.apache.org/manual/ anyway) I'll give a very simple example:

 <project name="example" basedir="." default="jar">
   <property name="sources" location="src" />
   <property name="builddir" location="build" />

<target name="compile"> <mkdir dir="${builddir}/classes" /> <javac srcdir="${sources}" destdir="${builddir}/classes" /> </target>

<target name="jar" depends="compile"> <jar jarfile="${builddir}/example.jar" basedir="${builddir}/classes" /> </target>

<target name="javadocs"> <mkdir dir="${builddir}/doc" /> <javadoc sourcepath="${sources}" destdir="${builddir}/doc" /> </target> </project>
So targets describe what you want to do (and can depend on each other, Ant will resolve these dependencies) and tasks (everything that's not project or target in the example above) know how to do this.

Ant comes with a wide range of tasks from simple one for copying files or creating directories to more sophisticated ones like javac (which will compile all outdated classes at once - using the same JVM as Ant - which makes it very fast, much faster than a make based process could ever be). See JavaUnitAndAnt for another interesting task that integrates Ant with JavaUnit.

Furthermore, it is very easy to write a task of your own.

One of the major design choices of Ant is that the core of Ant should be held as simple as possible (no loops, no pattern matching, no advanced conditionals) while the complex things get encapsulated inside of the tasks.


IBM has an article about using Ant and JavaUnit, see: http://www-4.ibm.com/software/developer/library/j-ant/?dwzone=java

AntHill adds the capability to build a project based on sources available in a source control repository, then increment a version number and tag the repository with the version number.

I would like to see an article describing Ant, Cvs and JavaUnit in a configuration a'la MartinFowler's ContinuousIntegration (http://www.martinfowler.com/articles/continuousIntegration.html).

There's actually a project under way to do this to produce something like this - checkout http://jakarta.apache.org/alexandria/.

Some people from ThoughtWorks have started an OpenSource project, named CruiseControl, that builds a wrapper around Ant for the ContinuousIntegration process outlined above.


Ant rocks. I'm using it to automate the administration of development and QA environments on my project, which involves checking out the codebase, compiling it, packaging it for deployment, deploying it in GemStonej and WebLogic, starting and stopping the application servers, etc. Portability is not my reason for using Ant. Prior to Ant, I was using custom-coded shell scripts. Ant build files are much cleaner, easier to maintain, and more powerful. I highly recommend Ant. -- RandyStafford


One should not iterate through subprojects. See RecursiveMakeConsideredHarmful.

Perhaps this needs its own page - AntPractices?


See also http://devguy.com/pctk, which also uses XML but is Windows specific and less extensible.

See also http://today.java.net/pub/a/today/2003/06/10/jython.html for using JythonLanguage instead of Ant (and JellyScript?).

Ant Tools: AntHill


Take a look at http://www.cpmake.org - it solves problems where ant and make are lacking. -- Brian


There is a Dutch saying that the chairs of a carpenter always squeak. Ant is a good example of a tool that we could never give to our customers but somehow seem to be willing to use ourselves. Ant does not fit in any model that I know of. The "depends", "target" and lack of "if" and "while" seem to suggests a declarative languages. But it isn't, the tasks have to implement any possible iteration or conditionals. However, the worst part is that tasks can not easily cooperate. The output of one task can not be used as the input of another task like a shell. The options of the tasks are extreme because of lack of chaining and lack of control functions in the basic ant. Over the past 25 years I learned a lot of rules about language design. Readability, predictability (properties!!!), consistency, simple. None of these rules seem to apply to ant. On top of this all, it is also a memory hog ... If you run into problems the following settings may help for HotSpot VMS: -XX:MaxPermSize?=356m

Some idiosyncrasies:

Unfortunately ant has become widespread (and seen as the best thing since sliced bread) which means it is hard to avoid, though I would never use it for projects I can control.

-- Peter Kriens


It is impossible to control the output of ant.

-Look at "loggers and listeners" in the docs; you can do anything with output that Java allows, or XML post processing permits. Color output is nice.

Output of targets cannot be chained,

-There is a special set of classes, filters, that chain together just like unix filter chains. Used mostly in text file processing, encoding, and other on-the-fly operations. Feel free to implement a sort filter and donate it to the project.

With ant, the commands only run in the ant shell.

-Why yes, It couldn't be cross-platform without it. Make doesn't have a shell either; these comparisons of Make vs Ant are really comparing Make+Unix with Ant. Of course Unix is richer, but not so portable.

Properties are weird

-yes, the first-setter-wins policy is the inverse of most apps. But it makes contained builds manageable, and so things like ApacheGump possible. Notice they are not called variables for a reason.

All dependency checking is done at the task level.

-Which is how Ant can manage dependency-driven updates inside ZIP or JAR files, FTP or SCP copies, or any other operation where the inputs and outputs are not normal file systems. To do that in Make, you need new virtual file systems mounted.

Everyone here seems to hate Ant because it pushes users to add new features in Java tasks, but that is the secret of Ant's many tasks. If you add something complex to Make, you have a makefile that you are scared of. If you do that in Ant's own build files, you have the same problem, only with angle brackets. But if you hide all the complexity in an Ant task, then anyone who loads the task gets access to all that you wrote; the dependency logic, the error handling, the parameter validation, the unit tests you have to also write to get your task into the Ant code base.

-- SteveLoughran


I think ApacheAnt and NantTool are really poor at what they do. It's about the worst use of XML I have seen - it's a real drag to edit and maintain these files. They are convoluted, and rather than lying on top of XML, they intertwine. They have horrible macro expansions in attributes, weird structures.

For DotNet, SConsTool is much easier to get working and better supported.


There is a semi-illegitimate child of Ant, MicrosoftBuild, which may become the standard DotNet build tool once VisualStudioWhidbey ships.


Ant is the most braindead, awkward, productivity killer of a build tool that I have ever had the misfortune to (have to) use.


See also AntTheDefinitiveGuide, AntPractices, AntUsageTask, NantTool, AntHill, JavaDevelopmentWithAnt, ApacheMaven, ApacheGump, SconsBuildTool, MicrosoftBuild, ConfigurationHell

CategorySoftwareTool, CategoryOpenSource, CategoryAnt


EditText of this page (last edited April 19, 2012) or FindPage with title or text search