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 was conceived by James Duncan Davidson while turning a product from Sun into Open Source . That product, Sun's reference JSP / Servlet engine, later became Apache Tomcat . A Closed version of ''make'' was used to build it on the Solaris Operating Environment , but in the open source world there was no way of controlling which platform was used to build Tomcat. Ant was created as a simple, platform-independent tool to build Tomcat from directives in an XML "build file". From this humble beginning, the tool has gone on to become more widespread - and perhaps more successful - than the Tomcat product for which it was created. Ant (version 1.1) was officially released as a stand-alone product on July 19, 2000. It has become the underpinning of open source Java; developers expect a "build.xml" file with every project.
The name is said to be an acronym for "Another Neat Tool". Coincidentally, the word "ant" was also used as an arbitrarily chosen project name in the paper ''Recursive Make Considered Harmful'' {Link without Title} , which described build-related problems that Apache Ant later proposed to resolve.
SAMPLE <CODE>BUILD.XML</CODE> FILE
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.
description="compile the Java source code to class files">
description="create a Jar file for the application">
---/---.class"/>
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'':
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 and 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 , , , ), 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.
EXTENSIONS
WOProject-Ant is just one of many examples of a ''task'' extension written for ant. These extensions are put to use by copying their jar files into ant's ''lib'' directory. Once this is done, these extension tasks can be invoked directly in the typical ''build.xml'' file. The WOProject extensions allow WebObjects developers to use ant in building their frameworks and applications, instead of using Apple'sXCode suite.
Antcontrib provides a collection of tasks such as conditional statements and operations on properties as well as other useful tasks
Other task extensions exist for Perforce , .Net , EJB , filesystem manipulations, just to name a few.
PORTABILITY
One of the primary aims of Ant was to solve make's portability problems. In a Makefile the actions required to create a target are specified as Shell commands which are specific to the current Platform , usually a Unix Shell . Ant solves this problem by providing a large amount of built-in functionality which it can then guarantee will behave (nearly) identically on all platforms.
For example, in the sample build.xml file above the ''clean'' target deletes the classes directory and everything in it. In a Makefile this would typically be done with the command:
rm -rf classes/ Rm is a Unix specific command which will probably not be available if the Makefile is used in a non-Unix environment such as Microsoft Windows . In an Ant build file the same thing would be accomplished using a built in command:
A common discrepancy between different Platforms is the way in which directory paths are specified. Unix uses a forward slash (/) to delimit the components of a path, whereas Windows uses a backslash (\). Ant build files let authors choose their favorite convention, forward slashes or back slashes for directories, semicolon or colon for path separators. It converts everything to the appropriate format for the current platform.
LIMITATIONS
Ant build files must be written in XML. Some consider this a barrier to new users as well as a problem in very large projects when build files can become very large and complex. This may be a problem common to all XML languages, but the granularity of Ant's tasks (compared to, say Maven ), means that the scalability problems arrive early.
Many of the older tasks—the core ones that are used every day, such as , and —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. ).
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
An article called " make: The Evolution and Alternatives "
presents Ant's
weaknesses, including a few not detailed above, fairly but without apology.
