What is Ant?

What is Ant? A simple definition might state that Ant is a Java-based build tool. Of course that definition may just raise the question in your mind "What is a build tool?". To answer that question, consider what is required to build a software system. Typically, there is much more to building software than just typing in and then compiling the source code. There is a number of steps required to transform the source into a deployable and useable software solution. The following is a hypothetical build process you might use with a simple software system

1. Get the source. You may need to download or fetch the source from a source code repository. For this, you might need to know the tag or version of the source code you want to build.
2. Prepare a build area. You will probably want to create a set of directories, perhaps according to some standardized directory layout.
3. Configure the build. In this step, you will determine what optional components can be built based on the current environment. You might want to set build numbers and version numbers to be included in the build.
4. Validate the source code. You may have a standard style guide and you wish to ensure all code conforms to this before you build a release.
5. Compile the source code
6. Build the compiled code into libraries potentially including non-code resources such as properties, images and sound files.
7. Run the system's tests to validate the build.
8. Build the documentation for the software. This may range from something as simple as collecting text files up to processing content through some form of publishing system to produce the documentation in its final form
9. Package up all of the components of the software – code, resources, images, documentation, etc. – into a deployable package. You might need to produce several packages in different formats for different target users
10. Deploy the software to some standard location for use or distribution

This is a high-level view of a software build process. A real-life build process may of course require many more and varied steps. Each of these steps may involve many individual operations.

If you try to use a manual process for building your software you would find it to be tedious, error prone and, in general, not very repeatable. You might forget to set the version number or to provide a tar file for Unix users. You might change the directory structure, confusing users who upgrade from the previous version of the software. Even worse, you may forget to test the software and ship a version that may not even work. Such ad-hoc build processes are always a source of problems and the best solution is to automate the build process. The tools you use to automate the build process are known, unsurprisingly, as build tools. Ant is such a tool.

In general, a build tool allows developers and build managers to describe the build process. In a build, some steps may need to be executed before others or they may be independent of others. In the example above, while the steps are laid out as a linear sequence, there are certain dependencies evident. Obviously, the source cannot be compiled until it has been fetched and the directory structure has been built. The directory structure, however, can be created before, or even while the source is being fetched. Fetching the source may be an expensive operation – perhaps accessing a remote server – and you may not want to do that every time you build the software. A build tool helps by only performing the operations that are required.

In summary, a build tool provides a mechanism to describe the operations and structure of the build process. When the build tool is invoked it uses this description, examines the current state of affairs to determine the steps that need to be executed and in which order, and then manages the execution of those steps.

Often developers will start the automation of their build process with scripting tools supplied by the operating system. Depending on your platform that might be a shell script, a batch file, a Perl script or, indeed, whatever scripting language is your particular preference. These scripts can be quite sophisticated but they usually fail to capture the structure of the build process and can often become a maintenance headache. Each time your code is changed, say adding a new source directory, you will need to update the build script. Since the build scripts are ad-hoc, new developers on your team may not understand them. Further, in many instances, such scripts perform all of the steps of a build even when only some are required. That is OK for build managers who will want clean builds but quickly becomes difficult for developers who may do many builds in a development session and need fast, incremental builds.

Java-Based

Those of you who are familiar with make will realize that the above description of a build tool is also satisfied by make. That isn't surprising since make is also a build tool. Makefiles provide the build description and make then organizes the execution of shell commands to build the software. One major difference between Ant and make is that Ant executes tasks implemented as Java classes. Make executes commands from the operating system's shell.

Being Java-based means a few different things for Ant. Ant largely inherits Java's platform independence. This means that Ant's build files can be easily moved from one platform to another. If you can ensure a homogenous build, development and deployment environment for the life of your project, platform independence may not seem important. For many softwre developments, however, development and deployment environments may be quite different. Open source Java projects, for example, have to support a number of target platforms. An Ant build file allows such projects to have and maintain a single build description. Even in closed source developments, the development and deployment platforms may be different. It is not uncommon for the development environments to be PC-based while production may use a Sun or IBM high-end Unix server. If these environments were to use different build descriptions, there is always the possibility, even the inevitability, of these descriptions getting out of sync. You tend to encounter these problems when production deployment fails, perhaps subtly, and it is usually an unpleasant discovery. Using the same build description throughout the project reduces the opportunity for such problems to occur.

Platform independence can sometimes be limiting, so some Ant tasks give access to the facilities of the underlying operating system. That puts the choice in the hands of the build file developers. Even when this is necessary, Ant will allow you to manage the bulk of the build process in a platform independent way, augmented with platform dependent sections.

Another aspect of Ant that is Java-Based is that the primitive build steps, known as tasks in Ant, are built in Java. These tasks can be loaded at runtime, so developers may extend Ant by writing new Tasks. You will also find many of the tasks that come with Ant are written to deal with the typical structure of Java projects. For example, the Java compilation task understands the directory structures involved in the Java package concept. It is able to compile all code in a source tree in a single operation.

Ant and Make

Both Ant and make are build tools. Many people have come to Ant from a make background looking to see what its strengths may be and why would they use Ant in preference to make.

Ant's website, reflecting the comments of James Duncan Davidson, Ant's original author, states that Ant is "like make without make's wrinkles". It turns out that many people are comfortable with make's wrinkles. If you are coming from a make background, you may miss the way make does things. You may wonder how Ant can really be a build tool without doing the things in the same way as make. You need to adopt a different mindset when developing an Ant build file than you would use when developing a Makefile. We'll look at the differences between Ant and make in a later section, once we have explored Ant to the point where such a comparison will make sense.

History of Ant

The following is a brief, albeit incomplete, history of Ant. It will give you a flavor for the evolution of Ant.

Ant started life as a quick hack by James Duncan Davidson to help building Tomcat, which was, at the time, Sun's servlet engine in development. Ant was originally developed on a Windows laptop, which some people find surprising. James was instrumental in the donation of the Tomcat codebase to the Apache Software Foundation by Sun to form the Apache Jakarta project. Included, indeed some might say tucked away, in that donation was Ant. Apparently the name started out as an acronym for "Another Neat Tool".

Ant was added to the jakarta-tools CVS repository on October 9^th, 1999. At this time, Ant was still considered part of the Tomcat project. It underwent development as part of the Tomcat project and at around Christmas 1999, Ant was released as a part of Tomcat 3.0. With this release, many people began to see Ant in operation and how it could be used to build software. Already people within the Apache Jakarta and XML projects had begun to use Ant to build other projects besides Tomcat. For example the Xerces XML parser project began using Ant in November 1999.

It became clear, with Ant's increasing popularity, that it was not really suitable to remain a part of Tomcat and that it should become a top level sub-project of the Apache Jakarta project. In February 2000, the code for Ant was moved to its own repository, jakarta-ant, at Apache. After some significant development work, Ant 1.1 was released in July, 2000. This was the first official release of Ant as a separate entity. To avoid confusion with the version released with Tomcat, there was never a 1.0 release of Ant. In the end, the original release as part of Tomcat 3.0 came to be known as Ant 0.3.

In November 2002, The Apache board promoted Ant to a top–level Apache project.

Since that initial release of Ant 1.1, there have been regular updates to Ant

With that brief introduction and history, you are ready to begin your exploration of Ant. There will be more Ant turorials to come …

Copyright © 2003, Conor MacNeill. All rights reserved.