Ant is a Java based build tool. In theory it is kind of like "make" without makes wrinkles and with the full portability of pure Java code.
According to Ant's original author James Duncan Davidson, the name is an acronym for "Another Neat Tool".
Later explanations go along the lines of "Ants are doing an extremely good job at building things" or "Ants are very small and can carry a weight a dozen times of their own" - describing what Ant is intended to be.
Initially Ant was part of the Tomcat code base when it was donated to the Apache Software Foundation - it has been created by James Duncan Davidson, who also is the original author of Tomcat. Ant was there to build Tomcat, nothing else.
Soon thereafter several open source Java projects realized that Ant could solve the problems they had with makefiles. Starting with the projects hosted at Jakarta and the old Java Apache project, Ant spread like a virus and now is the build tool of choice for a lot of projects.
In January 2000 Ant was moved to a separate CVS module and was promoted to a project of its own, independent of Tomcat. Ant became Apache Ant.
The first version of Ant that was exposed a lager audience was the one that shipped with Tomcat's 3.1 release on 19 April 2000. This version has later been referenced to as Ant 0.3.1.
The first official release of Ant as a stand alone product was Ant 1.1 released on 19 July 2000. The complete release history:
| Ant Version | Release Date |
|---|---|
| 1.1 | 19 July 2000 |
| 1.2 | 24 October 2000 |
| 1.3 | 3 March 2001 |
| 1.4 | 3 September 2001 |
| 1.4.1 | 11 October 2001 |
tar.gz distribution file. Why?Ant's distribution contains file names that are longer than 100 characters, which is not supported by the standard tar file format. Several different implementations of tar use different and incompatible ways to work around this restriction.
Ant's <tar> task can create tar archives that use the GNU tar extension, and this has been used when putting together the distribution. If you are using a different version of tar (for example, the one shipping with Solaris), you cannot use it to extract the archive.
The solution is to either install GNU tar, which can be
found here
or use the zip archive instead (you can extract it using
jar xf).
In order to find out which files should be compiled, Ant
compares the timestamps of the source files to those of the
resulting .class files. Opening all source files
to find out which package they belong to would be very
inefficient - instead of this, Ant expects you to place your
source files in a directory hierarchy that mirrors your
package hierarchy and to point Ant to the root of this
directory tree with the srcdir attribute.
Say you have <javac srcdir="src"
destdir="dest" />. If Ant finds a file
src/a/b/C.java it expects it to be in package
a.b so that the resulting .class
file is going to be dest/a/b/C.class.
If your setup is different, Ant's heuristic won't work and it will recompile classes that are up to date. Ant is not the only tool, that expects a source tree layout like this.
Use properties: ant
-D<name>=<value> lets you define values for
properties. These can then be used within your build file as
any normal property: ${<name>} will put in
<value>.
A couple of switches are supported via magic properties:
| switch | property | default |
|---|---|---|
| +E | build.compiler.emacs | false == not set |
| +P | build.compiler.pedantic | false == not set |
| +F | build.compiler.fulldepend | false == not set |
| only for Ant < 1.4, replaced by the nowarn attribute of javac after that -nowarn | build.compiler.warnings | true == not set |
The short answer is "Use <".
The long answer is, that this probably won't do what you want anyway, see the next section.
<exec> task?Say you want to redirect the standard input stream of the
cat command to read from a file, something
like
and try to translate it into
This will not do what you expect. The input-redirection is performed by your shell, not the command itself, so this should read:
Note, that you must use the value attribute of
<arg> in the last element.
See the section on IDE integration on our external tools page.
Ant adds a "banner" with the name of the current task in front of all messages - and there are no built-in regular expressions in your Editor that would account for this.
You can disable this banner by invoking Ant with the
-emacs switch. Alternatively you can add the
following snippet to your .emacs to make Emacs
understand Ant's output.
Yet another alternative that preserves most of Ant's formatting is to pipe Ant's output through the following Perl script by Dirk-Willem van Gulik:
An incomplete DTD can be created by the
<antstructure> task - but this one
has a few problems:
<taskdef> it won't know about it. See
this
page by Michel Casabianca for a solution to this
problem. Note that the DTD you can download at this page
is based on Ant 0.3.1.<test> and
<junit> tasks, there are two XML
elements named test (the task and the nested child element
of <junit>) with different attribute
lists. This problem cannot be solved, DTDs don't give a
syntax rich enough to support this.You can use XML's way of including external files and let the parser do the job for Ant:
will literally include the contents of common.xml where
you've placed the &common; entity.
In combination with a DTD, this would look like this:
You can use a custom BuildListener, that sends out an email in the buildFinished() method. Will Glozer <will.glozer@jda.com> has written such a listener based on JavaMail, the source is
With a monitor.properties like this
monitor.properties should be placed right next
to your compiled BuildMonitor.class. To use it,
invoke Ant like
Make sure that mail.jar from JavaMail and
activation.jar from the
Java
Beans Activation Framework in your CLASSPATH.
The antRun script in ANT_HOME/bin
has DOS instead of Unix line endings, you must remove the
carriage return characters from this file. This can be done by
using Ant's <fixcrlf> task or something like:
There is a bug in the Solaris reference implementation of the JDK, see http://developer.java.sun.com/developer/bugParade/bugs/4230399.html. This also appears to be true under Linux, moving the JDK to the front of the PATH fixes the problem.