Apache Ant Best Practices | Page 4

Apache Ant Best Practices

Reusing Prebuilt Libraries

In Chapter 2, "Tools of the Trade," I stated that one of the biggest issues with Java development is keeping track and control of all the third-party libraries a build requires. One of the ways to accomplish this is to maintain a library properties file. In this file, which I normally call library.properties (and create at the same level as the build.xml file), you define the exact version numbers and locations of the third-party libraries that the build requires. A sample library.propertiesfile is shown in Listing 5.3.

Tool Support for Managing Library Dependencies

There are a number of additional tools that you can use to help you manage library dependencies. Apache Maven, an alternative build tool to Apache Ant, has a sophisticated mechanism for dealing with library dependencies. With this tool you specify the versions of third-party libraries to be built against in its project description file (the Project Object Model). Then, when you build your application, Maven resolves the dependencies by downloading them from a central repository. This repository can be hosted locally but by default is hosted on the Internet at www.ibiblio.org. Maven has not yet reached the acceptance levels of Ant but it is certainly a product for the future. A similar tool for managing Java library dependencies is Ivy. This is not a widely adopted tool; however, it does have the advantage of being able to work directly with Ant build scripts, and it also supports resolution from Maven's ibiblio repository.

Listing 5.3 Sample library.properties File

This example specifies the exact versions of all the third-party libraries that the build uses and where to pick them up. By default they are picked up from the JavaTools libsdirectory. To make use of this particular properties file, you include it at the top of build.xml at the same time you include the other property files:

Then, when specifying the CLASSPATH for the build process, you explicitly include the .jarfiles as follows:

Since the location and names of the libraries being built against are based on property values, you have the flexibility to override them as before. For example, a developer trying out some new functionality (and versions of these libraries) could create the following entries in his private build.propertiesfile:

Again, I recommend recording the values of all the properties used during the build with the echopropertiestask.

Staging Library Dependencies in Clearcase

If you will version-control your library dependencies in ClearCase (either third-party or developed by you), you need to stage the objects in a suitable ClearCase repository or directory structure. Chapter 10, "The Art of Releasing," discusses the use of staged objects in more detail.

Ant ClearCase Integration

In terms of its integration with ClearCase, the Ant distribution already has a number of predefined tasks. These tasks are basically interfaces to the ClearCase cleartool command, with command-line options made available as task attributes. The complete list of tasks can be found online at https://ant.apache.org/manual/OptionalTasks/clearcase.html. Using these tasks to interface with ClearCase is quite straightforward. First, think of the commands you want to invoke (as cleartool subcommands) and the arguments that the commands need. Use the cleartool man pages to help you (such as cleartoolmanlockto look up the options for the lockcommand). Then map this command and its options to the particular Ant task that implements it. For example, suppose that, as part of your build process, you want to update the build snapshot view, lock the integration branch, and check out a file (that records the build version). A target to do this might look something like this:

This set of commands is functionally equivalent to the following ClearCase cleartool commands:

• cleartool update -graphical -overwrite -ctime
• cleartool lock brtype:project_int -replace -nusers ccadm
• cleartool checkout -nc -reserved src/com/ratlbank/model/Bank.java

However, one of the problems with this set of tasks is that a Java class exists for each cleartool command. This sounds fine in practice and allows a degree of argument checking. However, the caveat is that whenever IBM Rational Software adds or updates a cleartoolsubcommand, this integration becomes out of date and needs to be reworked. Similarly, the existing tasks do not support some of Ant's more powerful features, such as support for the element. A complementary approach is to use the third-party library clearantlib, which is described next.

URL: