XP and Ant
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.
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-systemspecific 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.
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