February 28, 2021
Hot Topics:

XP and Ant

  • By Sams Publishing
  • Send Email »
  • More Articles »

Ant and the XP Process

Ant is an open-source Java-based build tool that enables users to rapidly develop build and deployment processes by configuring an XML file. It's actually a framework that enables a developer to write an XML file that executes a series of actions, where Ant controls the main thread of execution. Ant is ideally suited for implementing XP. It provides the framework needed to set up automated builds, testing, and integration. Ant is also extensible, so if it doesn't have a required capability, the feature can easily be added. There is also an abundance of third-party tools that integrate easily with Ant. It's also possible to integrate tools that weren't designed for use with Ant (examples will be given throughout this book).

The role that Ant fulfills in build processes is analogous to the role that a tool such as InstallShield plays in installation programs. If you're developing an installer for a Windows-based product, using a product for building installers enables you to rapidly configure a very professional-looking installation. Certainly, you could write your own installer from scratch, but it would be time-consuming, with little value added. In the same manner, you can write your own custom build processes, but the question to ask is, "Am I adding value to the project by writing my own build tool?" Most likely, the answer is no. If the real goal is to reduce workload by creating a reliable, repeatable build process, it makes sense to use an off-the-shelf product.

Ant can be used to create a regular automatic build, such as a nightly build. It's a good practice to have such a process in place to routinely build and test the code that has been checked into the revision control system. Another recommended practice is to set up an account that is not associated with any particular developer and then have the build performed under that account. This detects problems caused by differences in the developer's respective environments, such as differences in environment variables.

Why Choose Ant?

Many choices exist for build and deployment processes besides Ant. What advantages does Ant have over other products? What advantages does Ant have over using nothing at all? Some of the options we'll consider in this chapter are make, various Integrated Development Environments (IDEs), and even custom in-house solutions (or proprietary solutions). We also consider why Ant is better than relying on a written process and performing the steps manually.

A major advantage of Ant over many other build tools is that it's platform- independent. Ant is written in Java. Therefore, it can be run on any operating system that has a Java Virtual Machine implementation, which is pretty much every platform. Additionally, Ant has the same logical behavior across platforms. This eliminates the need for special handling of conditions in your build process based on various operating systems that you must support. For example, if you want to create a directory tree, you specify the structure in your XML file. Ant takes care of the differences between operating systems, such as the use of a backslash in Windows but a forward slash on UNIX-based systems. Ant also has properties that can be referenced (like constants). You don't have to be aware of the operating system (unless you use the <exec> task, which enables you to make an operating-system–specific call).

Make is probably the most serious direct competitor of Ant. First, we should give make its due respect. Make was a tremendous step forward at its inception, enabling developers to create a file for command execution management that could be used to create a repeatable process. Many developers grew up on make and have successfully used it on numerous projects. Also, some common ground exists between make and Ant. Both (Gnu) make and Ant are free software, so cost is not a barrier for choosing either tool. Both can be used to create a build process and are basically platform-independent.

So, why do we consider Ant to be a superior alternative? The biggest advantages of Ant over make are its use of a standard syntax (XML), its rich feature set, and its extensibility. To the uninitiated, make syntax can be very cryptic, whereas XML is more intuitive and self-documenting. In fact, most developers are either familiar with XML or should become familiar with it in the near future.

As the Ant Web site (ant.apache.org) points out, make also has various quirks, such as the infamous tab problem. Probably every make user has had to debug a makefile problem that was caused by an unfortunate (and invisible) space in front of a tab in the file. A space in front of a tab in a makefile breaks the make process, and it's not always obvious that the problem is a space before the tab. In addition, different varieties of make have slightly different behaviors. Certainly, this problem can be circumvented by standardizing on a particular variety of make, such as Gnu make.

The other advantages mentioned are the rich feature set and extensibility of Ant. Substantial functionality is built into Ant in the form of core and optional tasks. If Ant doesn't have a built-in capability that you require, it's extensible in several ways. First, you can write your own functionality (tasks) in Java and plug it into Ant. Second, you can use the Bean Scripting Framework (BSF) scripting engine embed scripting code written in other languages (such as Perl, Python, JavaScript, and shell scripting) directly in your build process. Ant also has the ability to execute an operating-system–specific command, so it's also possible to integrate legacy scripts into an Ant process, easing the migration to Ant from proprietary processes.

Another reason for selecting Ant is that it uses current technology. Developers like to do work that will enhance their marketable skills. They generally don't like to work with technology that is perceived as outdated or as a dead end. It's easier to attract talented people to a project that uses leading-edge technology.

Finally, Ant is open source. This means that you can become a developer for Ant yourself and contribute to it. This also means that others have developed third-party add-ons for Ant. For more information about external tools and tasks for Ant, check the following URL:

Try doing a search on the Internet for a task that fits your requirements. If Ant doesn't already have a capability that you need, you might do a little research before writing your own; someone might have already solved the problem for you. In addition, you can post questions about Ant at mail lists or discussion forums to seek help from the user community. For more information about this, check the Apache Web site at

In fairness, make is a better choice than Ant in some situations. Ant is definitely Java-centric. In fact, it's written in Java. Although it's not imperative for a user of Ant to know Java, it is helpful. Some of the tasks, such as the commands to invoke the Java compiler (javac) or to create Java documentation (javadoc), simply are oriented toward Java. No built-in commands exist for invoking a C or C++ compiler: These can be added through BSF scripting, by writing an Ant task in Java, or by simply using the <exec> task of Ant to execute a command in the native operating system.

Projects that are being developed in C or C++ might be better candidates for make. If the development team has no experience with Java or with XML and is already very familiar with make, the cost of surmounting the learning curve might be not be worth the expense. Another situation in which make might be appropriate is a project with legacy makefiles. If these work well and can be easily maintained, there might not be a compelling reason to shift to Ant. In fact, unless using make actually causes a problem in terms of usability or maintenance, it doesn't make sense to rewrite a well-tested process. However, if a team has no experience with either make or Ant, we recommend Ant as the build and deployment tool of choice.

Page 4 of 6

This article was originally published on May 20, 2003

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date