- About Antlion
- Welcome
- License
- Search Antlion
- Sourceforge Home
-
- Download
- All Distributions
-
- Documentation
- Status
- Building
- Manual
-
- Contributing
- Guidelines
- Mailing Lists
- CVS Repositories
- Bug Database
- Feature Requests
- Donations
-
- Related
- Ant
-
|
The Antlion Project
|
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.
|
|
Status
|
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.
|
|
Goals
|
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:
-
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.
-
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.
-
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.
-
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.
-
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.
|
|
|