The ANT macro library

It was clear that continuing to use the existing build process was unsustainable, especially as the team was growing and required its members to be able to rapidly switch roles within it. Therefore, using the Development Policy as the basis for the team’s requirements, a new Ant macro library was developed.

Although there are many build systems available it was decided to keep using Apache Ant for two main reasons. Firstly, it is an XML based technology which would be familiar to the team, and secondly it would allow the team to re-use parts of the existing build system where appropriate. The various Ant macros in the existing build system were analysed for common code and functionality and a new library constructed using the following principles:

The macros in the library were developed over time but can be grouped into a few broad categories:

A number of XSLTs were also developed to work with these macros. These generally involved:

These XSLTs were deployed to a standard location on the CAPE where they could be referenced by the Ant macros.

It should be noted that most these macros are essentially wrappers around existing Ant functionality—but the value of the Ant library lies in this encapsulation of higher level functionality. For example, the deploy-files macro is really just a wrapper around the Ant <copy> task. However, deploy-files is aware of the context within which the team is working: team members merely supply a target path on the CAPE and a relevant file set and the macro does the rest.

This wrapper pattern has proved very useful in day to day use. For example, the standard deploy target for the CAPE is an anonymous Samba share hosted on a AWS EC2 Linux instance. This allows Ant’s basic <copy> mechanism (that works over file systems) to be used for deployment, as well as allowing developers to browse the deployment to check for correctness. However, a recently Windows 10 patch removed the ability for Windows 10 machines to connect to anonymous shares, which meant that those developers could no longer deploy any files. To get around this the deploy-files macro was updated to use optionally use ssh (Secure Shell) as a deployment mechanism. Once the relevant ssh keys were installed and configured they could carry on deploying assets with no changes required to their existing build files.