|
Apache Ant is a software tool for automating
software build processes. It is similar to make
but is written in the Java language, requires
the Java platform, and is best suited to building
Java projects.
The most immediately noticeable difference
between Ant and make is that Ant uses XML to describe
the build process and its dependencies, whereas
make has its Makefile format. By default the XML
file is named build.xml.
Ant is an Apache project. It is open
source software, and is released under the Apache
Software License.
Writing a Simple Buildfile
Ant's buildfiles are written in XML. Each buildfile
contains one project and at least one (default)
target. Targets contain task elements. Each task
element of the buildfile can have an id attribute
and can later be referred to by the value supplied
to this. The value has to be unique. (For additional
information, see the Tasks section below.)
Below is listed a sample build.xml
file for a simple Java "Hello, world"
application. It defines three targets - clean,
compile and jar, each of which has an associated
description. The jar target lists the compile
target as a dependency. This tells Ant that before
it can start the jar target it must first complete
the compile target.
|
<?xml version="1.0"?>
<project name="Hello" default="compile">
<target name="clean" description="remove
intermediate files">
<delete dir="classes"/>
</target>
<target name="compile"
description="compile the Java source
code to class files">
<mkdir dir="classes"/>
<javac srcdir="." destdir="classes"/>
</target>
<target name="jar" depends="compile"
description="create a Jar file for
the application">
<jar destfile="hello.jar">
<fileset dir="classes" includes="**/*.class"/>
<manifest>
<attribute name="Main-Class"
value="HelloProgram"/>
</manifest>
</jar>
</target>
</project>
|
Within each target are the actions
that Ant must take to build that target; these
are performed using built-in tasks. For example,
to build the compile target Ant must first create
a directory called classes (Ant will only do so
if it does not already exist) and then invoke
the Java compiler. Therefore, the tasks used are
mkdir and javac. These perform a similar task
to the command-line utilities of the same name.
Another task used in this example
is named jar:
<jar destfile="hello.jar">
This ant task has the same name as the common
java command-line utility, JAR, but is really
a call to the ant program's built in jar/zip file
support. This detail is not relevant to most end
users, who just get the JAR they wanted, with
the files they asked for.
Many Ant tasks delegate their work
to external programs, either native or Java. They
use Ant's own <exec> and <java> tasks
to set up the command lines, and handle all the
details of mapping from information in the build
file to the program's arguments -and interpreting
the return value. Users can see which tasks do
this (e.g <cvs>, <signjar>, <chmod>,
<rpm>), by trying to execute the task on
a system without the underlying program on the
path, or without a full Java Development Kit (JDK)
installed.
Limitations
Ant build files are written in XML. For unfamiliar
users, both XML itself and the complex structure
(hierarchical, partly ordered, and pervasively
cross-linked) of Ant documents can be a barrier
to learning. Moreover, the language Ant uses is
quite verbose and the build files of large or
complex projects become unmanageably large; good
design and modularization of build files can improve
readability but not reduce size. Other build tools
like Maven use more concise scripts at the expense
of generality and flexibility.
Many of the older tasks—the core ones that
are used every day, such as <javac>, <exec>
and <java>—use default values for options
that are not consistent with more recent tasks.
Changing those defaults would break existing tasks.
When expanding properties in a string or text
element, undefined properties are not raised as
an error, but left as an unexpanded reference
(e.g. ${unassigned.property}).
Ant has limited fault handling rules, and no persistence
of state, so it cannot be used as a workflow tool
for any workflow other than classic build and
test processes.
The Ant target model does not treat artifacts
as targets. In most build tools a target is an
artifact created by the build -- a program, library,
intermediate object file, PDF documentation, etc.
-- and rules specify the dependencies between
targets and the tasks to run to build a target
when it is out of date. In Ant a target is a group
of tasks rather than an artifact. This means that
Ant is sometimes unable to determine the relationship
between an artifact and the task sequence to build
the artifact and this logic must be implemented
by the programmer using Ant's control structures.
Once a property is defined it cannot be changed
by any of the core tasks. Antcontrib provides
a variable task to go around this problem.
Reuse of build file fragment is hard. Ant1.7 makes
it easier, with <import> and <macrodef>,
but this does run the risk of providing even more
complexity for new Ant users to get into trouble
with.
Apache
Ant |
Developer:
|
Apache Software
Foundation |
Latest release:
|
1.7.0 / December
19, 2006 |
OS: |
Cross-platform
|
Genre: |
Build Tool
|
License: |
Apache 2.0
licence |
Website: |
http://ant.apache.org
|
Click below to know more about
Apache Ant
Note :
Other Java-based build tools include Maven and
JavaMake
|
