Appendix K. The Deprecated XML-based Ant Backend

Table of Contents

K.1. The File
K.2. Directory Structure For Java Builds
K.3. Ant Hooks
K.4. JAR-like Archives
K.5. WAR Files
K.6. EAR Files


This appendix briefly describes the deprecated xml-based ant backend, which was the only mechanism for building Java code in abuild 1.0. To ease the transition to the newer Groovy-based framework, which still uses ant through Groovy's AntBuilder object, the old xml-based ant framework has been left largely intact. With one notable change, it works just as it did in abuild 1.0. New code should not use this framework. The rest of this appendix is mostly excerpts from abuild 1.0's documentation with explicit examples removed. The text may not be entirely coherent because of the omissions. Although much of the text is written as if this is the supported way to build Java code (which it was when the text was originally written), in no way should anything in this appendix be taken as a suggestion that this backend should be used for new code.

The one major difference is that abuild now invokes all Java builds from a single JVM. This JVM runs one build per thread up to the number of threads specified by abuild's -j option. In abuild 1.0, abuild actually ran an instance of the ant command, which it started with its current directory set to the output directory. Now, abuild launches ant through its Java API. Although the basedir property is still set to the name of the output file, certain poorly-behaved tasks that don't use that for local paths may find themselves resolving local paths relative to abuild's start directory instead of the output directory. This seems like a small price to pay though given that even the old ant framework runs many times faster using abuild 1.1's java build launcher as it prevents creation of a new JVM for each build.


There are two different build files that trigger use of the deprecated xml-based ant framework: for property-driven builds, and Abuild-ant.xml for build.xml-driven builds. The build.xml-based approach was introduced as a means to allow for greater flexibility in experimenting with alternative Java build approaches. However, as use of ant through XML files has been abandoned in abuild 1.1, it no longer serves any purpose. The way it works is that, if your build file is Abuild-ant.xml, abuild launches ant from the output directory using the source directory's Abuild-ant.xml as the build file. Other than having to resolve paths relative to the output directory rather than the directory containing Abuild-ant.xml as well as having access to the file, this was essentially just using ant to do your builds. Nothing further will be said about this method in this appendix. The remainder of the appendix will focus only on the property-based build method.

K.1. The File

The file is the build configuration file for Java build items. It serves the same function for Java build items as serves for platform-independent and C/C++ build items.

Below is a list of supported properties. You can also see this list by running abuild properties-help from any Java build item.


The name of the application.xml to put into an EAR file. This must be set (along with abuild.ear-name) for an EAR file to be generated.


The name of the EAR file, including the .ear suffix, to be generated. This must be set for an EAR file to be generated. EAR files contain any archive files in the abuild.classpath property. They do not contain JAR files in the abuild.classpath.external property.


A comma-separated list of build items from which hooks should be loaded. For details about using hooks, see Section K.3, “Ant Hooks”.


The name of the JAR file, including the .jar or other archive suffix, to be created by this build item. This must be set in order for a JAR file to be generated.

If specified, the value of this property will be used for the source attribute of the javac task. Otherwise, the value will come from the if set or from the Java environment used to run ant if not.

If specified, the value of this property will be used for the target attribute of the javac task. If is not set and this property is, then this property's value will also be used to set the source attribute of the javac task.


This property contains the name of the class that implements this build item's junit test suite. It must be set in order for the test target to attempt to run a junit test suite.


The name of a local build file, specified relative to the build item's directory, that will be imported by ant. It may contain additional properties that can't be specified in a property file, resource collections, or even additional targets. If you are using this too often, please consider whether a build item hooks file should be used instead, or whether there is some functionality that is missing from the core abuild ant framework code.


The name of a class, if any, that implements main. Setting this property causes the Main-Class attribute to be set in the manifest file. It also influences generation of the wrapper script if abuild.wrapper-name is set.


If set, ant runtime libraries will be included in the compilation classpath. This can be useful for compiling custom ant tasks.


If this and abuild.local-buildfile are both set, abuild will attempt to run hooks from the local build file as well as from any hook build items.


The name of the WAR file, including the .war suffix, to be generated. This must be set for a WAR file to be generated. WAR files contain any JAR files in the abuild.classpath property. They do not contain JAR files in the abuild.classpath.external property.


The type of the WAR file, which must be either client or server. This property determines where items in abuild.classpath are copied. For client WAR files, classpath JAR files are copied into the root of the WAR file where the are accessible to clients' browsers. For server WAR files, they are copied into the WEB-INF/lib directory of the WAR file.


The name of the web.xml to put into a WAR file. This must be set (along with abuild.war-name) for a WAR file to be generated.


If this property and abuild.main-class are both set, a script by this name will be generated that will invoke the Java runtime environment to invoke this main. The script will include the classpath as determined by abuild. On Windows, the script is usable to invoke the application from a Cygwin environment, and a stand-alone batch file (that does not reference the script or require Cygwin) is generated as well.

Note that at most of one abuild.jar-name, abuild.war-name, or abuild.ear-name may be set for any given build item.