Apache Ant is a Java-based build tool. In theory, it is kind of like Make, but without Make's wrinkles.
Why another build tool when there is already make, gnumake, nmake, jam, and others? Because all those tools have limitations that Ant's original author couldn't live with when developing software across multiple platforms. Make-like tools are inherently shell-based -- they evaluate a set of dependencies, then execute commands not unlike what you would issue in a shell. This means that you can easily extend these tools by using or writing any program for the OS that you are working on. However, this also means that you limit yourself to the OS, or at least the OS type such as Unix, that you are working on.
Makefiles are inherently evil as well. Anybody who has worked on them for any time has run into the dreaded tab problem. "Is my command not executing because I have a space in front of my tab!!!" said the original author of Ant way too many times. Tools like Jam took care of this to a great degree, but still have yet another format to use and remember.
Ant is different. Instead of a model where it is extended with shell-based commands, Ant is extended using Java classes. Instead of writing shell commands, the configuration files are XML-based, calling out a target tree where various tasks get executed. Each task is run by an object that implements a particular Task interface.
Granted, this removes some of the expressive power that is inherent by being able to construct a shell command such as `find . -name foo -exec rm {}`, but it gives you the ability to be cross platform -- to work anywhere and everywhere. And hey, if you really need to execute a shell command, Ant has an <exec> task that allows different commands to be executed based on the OS that it is executing on.
elements that indicate titles, headings, quotations, etc.Example
<?xml version="1.0" encoding="UTF-8"?>
<!-- address info for Ken Anderson -->
<person surname="Anderson" name="Ken">
<address>
<street>University of Colorado<br />
Department of Computer Science<br />
430 UCB</street>
<city>Boulder</city>
<state>CO</state>
<zip>80309-0430</zip>
</address>
</person>Now that we have reviewed XML, lets look at an example of an Ant build file (available here)
<?xml version="1.0" encoding="UTF-8"?>
<project name="binsearch" default="test" basedir=".">
<!-- set global build properties -->
<property name="src" value="src" />
<!-- auto-generated directories -->
<property name="build" value="build" />
<property name="dist" value="dist" />
<!-- generated jar files -->
<property name="binsearch.jar" value="${dist}/lib/binsearch.jar" />
<!-- filesets and paths -->
<path id="test.jars">
<pathelement location="${binsearch.jar}" />
</path>
<!-- project targets -->
<target name="compile">
<mkdir dir="${build}" />
<javac srcdir="${src}" destdir="${build}"
verbose="off" source="1.5" debug="on" deprecation="yes">
<include name="**/*.java" />
</javac>
</target>
<target name="dist" depends="compile">
<mkdir dir="${dist}/lib" />
<jar jarfile="${dist}/lib/binsearch.jar" basedir="${build}" />
</target>
<target name="test" depends="dist">
<java classname="binsearch.BinarySearch" fork="yes">
<classpath refid="test.jars" />
<jvmarg value="-Xms100m" />
<jvmarg value="-Xmx200m" />
</java>
</target>
<target name="clean">
<delete dir="${build}" />
<delete dir="${dist}" />
</target>
</project>
A property looks like this:
<property name="binsearch.jar" value="${dist}/lib/binsearch.jar" />
As you can see it defines a property name and gives it a value. The value of a property is referenced using the following syntax:
${propertyname}
and as you can see, properties can reference the value of other properties when defining their own value.
Each target is made up of a set of tasks; as mentioned previously, each task is defined via an XML element and has parameters that can be assigned via attributes and sub-elements. Take, for example, the compile target below:
<target name="compile">
<mkdir dir="${build}" />
<javac srcdir="${src}" destdir="${build}"
verbose="off" source="1.5" debug="on" deprecation="yes">
<include name="**/*.java" />
</javac>
</target>It consists of two tasks, one that creates the build directory and one that invokes the javac compiler to compile the Java files contained in the src directory.
As you can see the open tag for the javac task contains a bunch of attributes that are used to configure the command line arguments passed to the javac compiler when it gets invoked.
Furthermore, the include element is used to specify which Java files should be compiled by the compiler. The funny “**/*.java” syntax simply indicates that all java files contained in the source directory should be compiled no matter how deep they appear under the source directory.