Tech Articles J2EEAn Ant script is an XML file which is used to define targets which run various Ant tasks as a part of your build procedures. The Ant structure is made up of target elements which then contain task elements. Target elements can specific depends attributes which require the specified targets to be run at least once before the current target starts. Each target will contain task elements which carry out the work of the build script.
An Ant script is an XML file which is used to define targets which run various Ant tasks as a part of your build procedures. The Ant structure is made up of target elements which then contain task elements. Target elements can specific depends attributes which require the specified targets to be run at least once before the current target starts. Each target will contain task elements which carry out the work of the build script.
An Target holds a collection of tasks and may depend on other tasks.
A Task does the work of the Ant script, such as running javac.
Your project should define a standard set of targets, such as compile, test, clean. Each target defines other targets with the depends attribute. Ant will ensure that each dependency has been run at least once and in the order that you have specified in the depends attribute. Ant does not support loops or conditional statements to control the flow of a build process. Instead you must set up a sort of cascade effect for your builds. That means the starting target will strongly determine how the build progresses. The goal here is to create a repeatable and reliable build process.
Each target in the very least should depend on an init target which loads the build.properties and creates the required directories for the rest of the build process. The init target may define the working directory and then attempt to create it. The loaded properties may also define the build environment and database settings to use in the unit tests. Ant also relies on references to define file sets and classpaths. The init target is a great place to define them all.
Complex processes may require many targets to be run in a certain sequence. You may be tempted to use the antcall task to run the targets in order.
The Wrong Way, with Antcall
<target depends="init" name="runall">
<javac destdir="${bin.dir}" optimize="true" srcdir="${src.dir}">
<classpath refid="jarset"/>
</javac>
<antcall target="test" />
<antcall target="javadoc" />
<antcall target="package" />
</target>
In contrast, it is much easier to simply use an empty target with an ordered list of dependency targets to call each target.
The Right Way, with Depends
<target depends="init,compile,test,javadoc,package" name="all"/>
Personally I simply will not use the antcall target. It causes more headaches than it is worth due to properties inheritance and the inability to retain properties that are set in called targets. Alternatively, the ant task, not antcall, can be useful for calling Ant targets in other Ant scripts. It provides for delegation of build processes and reduces the size of the main build script. If you use it you will want want to keep each Ant script extremely independent of other scripts. With the project broken up into many components a master build file can provide the standard Ant targets for compile, test and clean while the specific components can provide additional targets or specific compile and test requirements. Each component will still have a compile target so the main build can call each of them in sequence to produce the project as a whole.
With a master build script using the ant task to call the components build scripts it is still possible to load the same properties files. Typically there will be the main file, build.properties, but specialized files may be helpful for separating component specific properties. If the main build script uses the ant task to call a component build script it can inherit previously loaded properties, and it does that by default, but in order maintain independence it is best to disable inheritance to force the component script to load the properties files itself even if it is the same file. Then you can run the component script without the main build script and it will still function the same.
One of the properties files can hold all of the names for the library files used for each of the components in the project. The properties file naming these library files can be updated to point to the new file to keep the build running.
libraries.properties
libs.dir=c:/wsad/workspace/nofluff/libs
jar.xerces=${libs.dir}/xerces.jar
jar.junit=${libs.dir}/junit3.7.jar
jar.jakarta-regexp=${libs.dir}/jakarta-regexp-1.2.jar
jar.commons-lang=${libs.dir}/commons-lang-1.0.jar
The init target in the build scripts can then assemble the necessary classpath needed to compile the components as well as the set of files used to produce a deployment file. The path set in the init target is then later used by the javac task in the compile target.
<target name="init">
<property file="libraries.properties"/>
<property file="build.properties"/>
<mkdir dir="${bin.dir}"/>
<mkdir dir="${lib.dir}"/>
<mkdir dir="${javadoc.dir}"/>
<path id="jarset">
<pathelement location="${jar.xerces}"/>
<pathelement location="${jar.junit}"/>
<pathelement location="${jar.jakarta-regexp}"/>
<pathelement location="${jar.commons-lang}"/>
</path>
<echo>
jarset:
${jar.junit}
${jar.log4j}
${jar.mysql}
${jar.jakarta-regexp}
${jar.commons-lang}
</echo>
</target>
<target depends="init" name="compile">
<javac destdir="${bin.dir}" optimize="true" srcdir="${src.dir}">
<classpath refid="jarset"/>
<!--<exclude name="**/test/*.java"/>-->
</javac>
</target>
