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:

TestingFramework: AntUnit
AntContrib Tasks

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:

It is impossible to control the output of ant. In make you could use @ to to remove clutter so you could decide what was seen on the console. Ant prints the useless [xxxx] on 2 lines which makes the output always very verbose. ''Except for ant -q"
Output of targets cannot be chained, making it impossible to use small simple, easy to understand commands (sort, uniq, wc, grep, sed, etc.) that are combined to achieve a higher goal.
The unbearable lightness of the ant shell means that targets must implement functionality that is normally implemented in different commands or built in. Worse, it means that it is absent. Some commands support an if/unless (!) attribute, others don't. Worst, sometimes similar concepts have different names.
With make it is possible to run the commands in a shell to get them right. With ant, the commands only run in the ant shell.
Properties are weird (make properties were not always predictable, but ant seemed to be able to have beaten the weirdness). The first who sets a property owns it. They can no longer be overwritten. Great for loops. Oops, forgot, standard ant does not have loops. Properties that are not set have a default value which equals their name + clutter. This makes it impossible to test if a property is set because it will return its own name. This forces you to give it a value and test for that value. Then again, testing a property is already a pain in the a.. and only works if the task was so friendly to implement an if attribute, oh and then of course an "unless" because expressions are way beyond ant's comprehension.
Target has this nice familiar ring for makers, however ant targets are no such thing. I guess they could be called "procedures" but the lack of procedural constructs makes it sound like too much honor. They are also not clauses from functional languages. So I am not sure how they should be called but a function comes closest. And when we are at it, depends is not doing dependency checking, it is just chaining the call in a rather weird way. In make a target is a artifact, and that is how it imho should be.
Forget about dependency checking on ant level. All dependency checking is done at the task level.

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.

CategorySoftwareTool, CategoryOpenSource, CategoryAnt