Apache Ant Best Practices | Page 3

Apache Ant Best Practices

Automated Baseline Numbering

One of the most important aspects of software build automation is the reliable and consistent generation of build or release baselines. Baselines should be generated in a standard format. You also should be able to determine the baseline's quality simply by inspecting it. As I discussed in Chapter 3, "Configuring Your SCM Environment," with Base ClearCase this can be achieved via the baseline's name or through an attribute, and with UCM this can be achieved by using UCM baseline promotion levels. If these baselines are also "built" into the application, such as into a help file or .jarfile, they can be extremely useful in debugging test or live problems.

One recommended way to automatically generate Release Build baselines is to use Ant's task to automatically increment a build number. Ant does this by creating and updating the entries in a properties file; by convention, this particular properties file is called buildinfo.properties. When you start making use of this property file, I recommend creating an entry (called name.build.infoor something similar) in the default.propertiesfile to refer to it. At the same time, create an entry (called name.build.refereror something similar) that refers to a (single) source file or a Web page that should be updated with the automatically generated baseline. For example, the additional entries that can be added to your default.propertieswould be as follows:

The name.build.prefixentry prefixes any labels or baselines that are created.

To insert the baseline into the file that the name.build.referer entry points to, some sort of marker must be placed in that file to be able to search for and replace it. If this file was a Java source file, one way to do this would be to create a Java static string called version:

The beginning @(#) and ending @ strings are simply tokens to be used for searching and replacing. This string could be displayed in a log file, in an About box, or wherever you need information about the version of the application that is running. To generate the build number, you would include a task in the build.xmlfile:

This task writes (and increments) a build number into the buildinfo.propertiesfile in the format 0000, 0001, and so on. It also writes the current date. Here's an example of the contents of a typical buildinfo.propertiesfile:

I recommend adding this file to version control and subsequently checking it in or out when it is updated. This way, the last build number is always preserved.

Once this build number has been generated, it can be used as part of a baseline to be placed across all the build files. To actually write the baseline into the Java source file containing the version string described earlier, you can use Ant's task to carry out a search and replace:

Note that the baseline is prefixed with the name.build.prefix entry from the build.properties file, so in this case the baseline would be something like RATLBANKMODEL-0006. In fact, this task searches for this expression:

and replaces with the following:

For example:

In case you are wondering why I chose the strange combination of tokens @(#), this is a bit of UNIX history. On certain UNIX systems, if a static string containing these tokens was built into a program, you could use the SCCS whatcommand to extract its information—for example, what /bin/ls. This command was always extremely useful in debugging test and live problems!

URL: