Keep the Ant, Hold the XML (Continued)

While the Ant property tag works like a variable, it has significant limitations when compared to true variables. Properties can contain only strings. They do not permit direct manipulation of numerical data, such as enabling you to increment an integer easily. In addition, no provision exists to limit unwanted manipulation of these properties by making them private or protected. Using Java to code Ant tasks addresses these limitations by making the full range of variables available and permitting limitations to the access of these variables.

The command-line structure of XML builds restricts targeted users to a fairly sophisticated audience. Even to execute an Ant file often requires the user to carefully enter cryptic code to customize the build. Consider a project that uses a property to communicate the location of a particular file. If this file is nested within a tree structure, just typing the complete file name can be tedious and prone to errors. When Ant tasks are called programmatically, nothing prevents you from placing the project within a GUI. The process of customizing the build can then be managed in a point-and-click manner. Instead of requiring the entry of absolute directory paths and file names into a command line, the program can display a file chooser to assist in the selection of the specific target file.

To execute XML builds requires the installation of Ant, and often a specific version. Using Java, you can design builds that need only the ant.jar archive, a much smaller amount of code that you can archive efficiently with your programs. This archive allows for execution without the installation of Ant and packages your code with the correct Ant version.

On the other hand, using any tool in a manner that its makers never intended always entails risk. Ant's designers expected it to be called by XML tags. They did not write their classes to be accessed programmatically. Unexpected errors often creep in when tools are used in unplanned ways, which may be a good argument for avoiding the use of programmatic Ant. My experience has shown me, however, that the care taken in the writing of Ant classes makes them work predictably even when invoked in a nonstandard manner.

Successful Builds
The Apache Ant manual provides almost no information about implementing Ant tasks programmatically. The entire discussion of the subject consists of reviewing the pros and cons of such use, presenting one example, and then ending with a somewhat unhelpful conclusion.

The question you are probably asking yourself at this point is: how would I know which classes and methods have to be called to set up a dummy project and target? The answer is: you don't. Ultimately, you have to be willing to get your feet wet and read the source code. Go for it!

Programmatic Ant is not difficult to implement, however. Experimentation has shown me that following some simple policies helps to create successful programmatic builds. For instance, most of the classes you need to include in your builds are contained in two directories within the Ant archive. You can find tasks that correspond to specific build commands in org.apache.tools.ant.taskdefs and types that support these tasks in org.apache.tools.ant.types.