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.