Apache Ant Best Practices | Page 2

Apache Ant Best Practices

The Configurable Build

One of the problems of having a single, centralized build file is that there may be times when you want to change things slightly to carry out different build scenarios. For example, developers might want to override the standard optimization or debug settings. Similarly, when you change the details of an existing project or create a new project, you might have to rework a build file significantly. One of the ways to address both of these issues is to maintain property files that define default and overrideable property values. One convention for this is to create a file called default.properties (in the same directory as the build.xml file). It defines default values for the set of properties that would be required as part of a "normal" build. For example, the default.propertiesfile for our RatlBankModel project might look like Listing 5.1.

Listing 5.1 default.properties File

In this file you can place both project build information (compiler settings) and ClearCaserelated information (the name of the UCM project, the ClearCase admin user, the build branch, and so on). As with any other important software development asset, this file should be placed under version control in ClearCase. In the same location, you can also create a file called build.properties. This file should contain any of the properties from the default.properties file that a user wants to override. For example, a developer's build.properties file might look like Listing 5.2.

Listing 5.2 build.properties File

This file should be created by each user as and when he or she needs to override particular values. Consequently, it should not be placed under version control. To make use of these two property files, you have to include a reference to them in the build file. You can do this by including the following lines at the top of the build.xmlfile (usually before the definition of any targets):

The order is important here. Since in Ant all properties are immutable, they cannot be changed after they are set. Therefore, if a property value is defined in the private build.propertiesfile, it cannot be changed by the value in the default.propertiesfile. Given this scenario, it is therefore possible to write tasks that use these defined property values as follows:

Once these properties exist in a file, it is also possible for users to identify and override single entries from the command line. For example, to override the value.compile.debugsetting in the preceding example, Ant could be called as follows:

Having this capability could be seen as an audit or security loophole. For example, if during a Release Build a particular property is overridden, where is the information on this override recorded? To avoid this, I recommend that as part of your Release Build you record the values of all the customizable properties that are used. You can use the task, as follows:

This command echoes all the properties that begin with the prefix name or value to the Ant log file.

Automatically Prefixing Build Properties

If you want all your imported build properties to have a standard prefix, such as bp., when you load the property file, you can specify the prefix at the same time. An example is . This also makes it easier to log the properties using the echopropertiescommand.

URL: