Table of Contents
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:
Abuild-ant.properties 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 .ab-dynamic-ant.properties 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.
The Abuild-ant.properties file is the build
configuration file for Java build items. It serves the same
function for Java build items as Abuild.mk
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 abuild.java-target-version
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
abuild.java-source-version 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.