The Antlion Project adds value to Apache Ant by adding lightweight tasks for depedency analysis and build-file augmentation. It focuses on handling three things: managing the library repository representation in Ant, defining build artifacts and their dependency, and calling external artifact builds.

Antlion is released under the Apache License version 2.0, the same as Ant. If you can use Ant, you can use Antlion.

You can view the manual online here.

Antlion version 0.9.0 has been released. Contains a lot of refactoring of code, and increases the ease of customization. This should be considered a stable version, as the next release will be the 1.0 release candidate. See the status page for more details.

Antlion focuses on providing easy dependency managment in Ant build files, without forcing a style on the user. To do this, the tool has these goals:

1. No pre-defined library structure. Many tools try to manage third-party dependencies, too, such as Savant and Maven and Maven-like plugins for Ant. However, these all suffer from the same issue where the user must follow their naming convention for libraries. Antlion allows the user to define the library structure, and where to find the libraries.
2. Integrating builds and their outputs. One "strength" or "weakness" to Ant, depending on your viewpoint, is that the build targets don't necessarily relate to an output based on a source, such as what standard Make provides. Antlion allows for the definition of an Artifact, which knows about an output file, its source and library dependencies, and where it gets built. The task to have one project build depend upon the output of another project build becomes trivial.
3. No external files to Ant. Antlion keeps the library definitions and the Ant build scripts all in one place - the build scripts. You don't need to jump between files to find where that library was defined. Of course, starting with Ant 1.6, you can put the library definition in its own file and <include> it in another. That's a decision left up to you.
4. Don't force a library version. One weakness to most library management tools is that they assume that a library depends upon only one version of another library. That is, if you define a Xalan library, it doesn't force anyone who uses that library to use its defined version of Xerces. In progress for release with Antlion 0.7.0: a library can define its dependencies as being compatible with multiple library versions. This is particularly useful when testing a project for compatibility with multiple library versions.
5. Define it once. If you define a library once, you shouldn't need to go and create the corresponding <path> and <fileset> references for it.

For very simple builds, Antlion can be overkill. However, if the build contains many external dependencies, then Antlion helps organize these. Antlion really shows its power when you need to maintain large build projects, with many external dependencies and inter-project dependencies.

Antlion projects usually start by defining a policy, which includes repositories and how to process the libraries.

Once the policy has been established, then the projects proceed to define the libraries and artifacts for the build. Now, all the defined meta-data can be referenced directly from the Ant build file, as standard Ant types.

If needed, the build can reference a dependency upon an external artifact, and build it if needed using subprojects.