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:
Macro definitions would be used rather than custom Java code. This would be simpler to maintain and would not require additional skills beyond XML.
Modular code: related macro definitions would be grouped
together as files/modules to minimize the number of
<include> statements required.
Documentation for each of the modules would be included in the
module itself (as Markdown in the
<description> tag, as described above)
and automatically generated for deployment to an internal web
site.
Common sense naming conventions were followed: for example, the file “compile-schematron.xml” contains macros involved in Schematron compilation and so on.
Performance of the build system was not considered to be an issue; instead maintainability of the code by the whole team was considered to be more important.
Additional configuration tools like Ivy and Maven were also not involved, again for simplicity and maintainability reasons.
The macros in the library were developed over time but can be grouped into a few broad categories:
XML operations, such as compiling Schematron files, validating XML instance documents and so on.
Deployment of files using a variety of mechanisms.
Wrappers around shell commands/system executables, such as git, ssh and so on.
Utility macros used by other macros.
A number of XSLTs were also developed to work with these macros. These generally involved:
Extracting Markdown documentation from Ant build files, XSLTs and Schematron.
Filtering and converting SVRL reports.
Modifying Schematron files in a number if ways, for example to display report and assert IDs in their respective messages.
General utilty stylesheets to modify XML documents in various ways (remove documentation elements, linearise XML files etc).
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.