One aspect of Antlion helps in the description of what you're building, called artifacts. It's an overloaded term in build scripts, so here's how Antlion uses it: an artifact describes something that a build will produce that should be preserved after the build completes. In some cases, an artifact may be preserved only for consumption by another project, while, more commonly, in other cases the artifacts may be published for external consumption.

Antlion uses the <artifact> task to contain all the meta-data related to an artifact: what file or directory was built, what was used to build the artifact, and what dependencies are in the artifact. This task was developed so that the paths it uses are relative to the directory containing the task, rather than relative to the directory of the invoked build file. This allows a project to create a separate file to house the artifact descriptions, so that it may be used by other projects. By convention, this file is called artifacts.xml file, and is placed in the same directory as the build.xml file.

artifacts.xml

So, we create our artifacts.xml file to define what we're building, and also what is used to build them. For our sample project, we'll be exporting two jar files: the main code and the unit tests. I have found it convienient to construct a target whose purpose is to expliticly construct just the artifact, so in our artifact definition, we use artifact::jar and artifact::tests-jar, which will be defined below. Since this file is not a stand-alone build file, many of the <project> decorators can be removed. We give the project a unique name for easier reference. <project name="SimpleProject-artifacts"> <artifact id="simpleproject.jar" target="artifact::jar" location="dist/simpleproject-1.0.jar" policyRef="policy"> <src dir="src/java" filesetId="fs-src.simple"> <exclude name="**/package.html" /> </src> <src dir="src/java" name="non-java" filesetId="fs-other.simple"> <exclude name="**/*.java" /> <exclude name="**/package.html" /> </src> <depends name="build" manifest-classpath="mfcp.simpleproject.jar"> <library id="lib.xerces" group="xerces" version="2.6.2"> <entry name="xmlParserAPIs" /> <entry name="xercesImpl" /> </library> <entry group="log4j" version="1.2.8" /> </depends> </artifact> <artifact id="simpleproject-tests.jar" target="artifact::test-jar" location="dist/simpleproject-tests-1.0.jar" policyRef="policy"> <src dir="src/tests" filesetId="fs-src.simple-tests"> <exclude name="**/package.html" /> </src> <src dir="src/tests" name="non-java" filesetId="fs-other.simple-tests"> <exclude name="**/*.java" /> <exclude name="**/package.html" /> </src> <depends name="test"> <artifact refid="simpleproject.jar" /> <dependencies type="build" artifactRefId="simpleproject.jar" /> <entry group="junit" version="3.8.1" /> </depends> <depends name="build"> <!-- this creates a local build file dependency, but this should be okay, since only the local build file should compile --> <entry location="${classes.dir}" type="dir" /> <dependencies type="build" artifactRefId="simpleproject.jar" /> <entry group="junit" version="3.8.1" /> </depends> </artifact> </project> So now we have a defintion of our two artifacts. They describe: Where to find the artifact. This is defined in the location attribute; remember that this path is relative to the location of the artifacts.xml file. How to build the artifact, defined by the target attribute. By default, this defaults to assume that the Ant script that contains the target is in the same directory as the artifacts.xml file, and is named build.xml. What is used to build the artifact. The <src> elements construct <fileset>s, which can be used in the definition of the Ant tasks. They are also used indirectly to discover if the artifact file needs to be recreated. What dependencies the artifact has, defined in the <depends> element. These use the policyRef of the <artifact> task in order to resolve the libraries. The policy will be described later, and with it the full meaning of these dependency definitions. Of note is the test artifact's dependencies. The "test" dependency declares that it requires the main artifact and its dependencies, along with an additional jar. The "build" dependency adds a hard-reference to the output classes directory (defined in the next section) instead of the jar artifact, which is more useful when compiling the test classes.

Adding Artifacts Into Our Build

Now that we've described our artifacts, we need to let our build file know about them. We do this by inserting an import task after the Antlion task definition: <project name="SimpleProject" default="main"> : <typedef resource="net/sf/antlion/antlib.xml"> <classpath><pathelement location="${lib.dir}/antlion/0.9.0/antlion-inline-0.9.0.jar" /> </classpath></typedef> <import file="artifacts.xml" /> </project>