The project file format is very similar to that of Ant 1. The root element of the project file must be a <project> element. It can take the following attributes:

Attribute	Description	Default Value
name	The project name.	The base-name of the project file, with the extension removed.
basedir	The base directory for the project. The base directory is used to resolve all relative file names used in the project file.	The directory containing the project file.
default	The name of the default target.	main
version	The project file version that the project is written for.	None, must be 2.0

A <project> element can contain the following elements, in the order given below:

• <projectref>
• <import>
• Implicit tasks
• <target>

Project References

Project references allow the project to import, or reference, other projects. A <projectref> element takes the following attributes: Attribute Description Default Value name The name to use to identify the referenced project. Required location The path to the project file to reference. Required The targets of a referenced project can be used in the depends list of a target in the referencing project, using the following syntax: project-name->target-name. Here is a simple example: <project version="2.0"> <!-- Reference another project --> <projectref name="subproject" location="subproject/build.xml"/> <!-- Use the "compile" target from the referenced project --> <target name="main" depends="subproject->compile"> .. do some stuff .. </target> </project>

Library Imports

Library imports allow the project to import the tasks and data-types from an antlib. An <import> element takes the following attributes: Attribute Description Default Value library The name of the library to import. The ext directory of the Myrmidon distribution is searched for a library file with the given name, and an atl extension. Required type The type of definition to import. Values include task, and data-type. None name The name of the type to import. None If the type and name attributes are not provided, the entire contents of the antlib are imported. The following example import the <my-task> task from the my-tasks antlib. <project version="2.0"> <!-- Import task <my-task> from the 'my-tasks' antlib. --> <import library="my-tasks" type="task" name="my-task"/> <target name="main"> <my-task some-prop=".."/> </target> </project>

Implicit Tasks

Implicit tasks are run before any of the project's targets are run. Any task can be used, including <property> and data-type instances. Implicit tasks can be used to initialise the project. For example: <project version="2.0"> <property name="some-property" value="some value"/> <path id="classpath"> <fileset dir="lib"/> </path> <log>Set classpath to ${classpath}</log> <target name="main"> .. do some stuff .. </target> </project>

Targets

Targets have a similar format to targets in Ant 1.x, though some of the behaviour is different. A <target> element takes the following attributes: Attribute Description Default Value name The name of the target. Required depends A comma-separated list of targets that this target depends on. This list can contain targets from referenced projects. None

Listed below are some of the current set of tasks. You can find example usages of these tasks in the sample project file src/make/sample.ant.

<condition>

Sets a property if a particular condition is true. See Conditions for a list of available conditions.

<fail>

Causes the build to fail.

<if>

Conditionally executes a set of tasks.

<load-properties>

Loads a set of properties from a file.

<log>

Writes a log message.

<property>

Sets a property.

<try-catch>

Runs a set of tasks, with a provided error and clean-up handler.

<converter-def>

Register a type converter. These are used when configuring a task or data-type from attributes.

<type-def>

Register a task or data-type.

<import>

Register the contents of an antlib.

The following conditions are available

<and>

Evaluates a set of nested conditions, and AND them together. Evaluation is lazy. An empty <and> condition evaluates to true.

<available>

Tests if a particular class or resource is available.

<file-test>

Tests a file against a set of file selectors.

<is-set>

Tests whether a proeprty is set, and not set to 'false'.

<or>

Evaluates a set of nested conditions, and OR them together. Evaluation is lazy. An empty <or> evaluates to true.

<os>

Tests which operating system the build is running on.

<not>

Negates a nested condition.

The following file name mappers are available:

<chain>

Applies a set of nested file name mappers to file names.

<flatten>

Maps all file names to a single directory.

<prefix>

Adds a prefix to the front of each file name.

<map-extension>

Changes the extension of file names.