AspectJ build

This build module contains taskdefs and resources for doing builds and checking source licenses.

Usage

Running the build

To do a build, use Ant to run build.xml from this directory. To run Ant, use ../lib/ant scripts and libraries. Consider defining the following flag properties:

PropertyEffect of setting it to any value
check.build.jar fail if build.jar is out of date

Release builds: Release builds differ only in running from a clean, up-to-date tree and with correct build version values in build-properties.xml, which will update org.aspectj.bridge.Version. See below for more details on how the version is updated.

Updating module dependencies and file locations

Because the BuildModule taskdef extracts dependencies from the Eclipse .classpath file, there is no need to update build scripts when adding or removing modules or changing their dependencies, so long as they are all in the base modules directory (usually the base of the eclipse workspace. All required libraries are checked into the lib module.

The BuildModule taskdef makes some assumptions about the naming, position, and contents of module directories and files. Understand those (documented in BuildModule.java) before using non-standard module directories.

Running builds or built jars under Eclipse

When running Ant from eclipse, do not use the default Eclipse Ant classpath; remove those jars and add all the libraries in ../lib/ant/lib as well as in ../lib/junit.

warning: Jar files do not seem to be closed properly when running under eclipse. This affects build products (e.g., installers) which are run under eclipse (e.g., by opening with the "default system editor") and libraries used when compiling under Javac (if not zip products or input). This problem presents as files not being writable, i.e., deleted or modified. You might get no notice of the problem when deleting with quiet="on". (The alternative to that is to create any directories being deleted before deleting them).

Currently BuildModule taskdefs fork the Javac command to work around this problem, but the Zip commands do not work around it. If under Eclipse, you get strange behavior with Ant builds, clear out everything and build from the command line. In some cases, you have to exit Eclipse before files can be deleted. (*sigh*)

Development

BuildModule task

The BuildModule taskdef implements an integrated module or product build. Module builds are based on the Eclipse .classpath file, and can produce a jar with the module classes, with two variations: (a) include only the module classes, or assemble the jar complete with all antecedent modules and libraries; and (b) compile the module(s) without any testing source or libraries. If there is a file {moduleName}.mf.txt in the module directory, it will be used as the manifest for the module jar file. Product builds are defined by introspection of a products subdirectory like products/tools for the AspectJ tools installer. These have an install directory for installer resources and a dist directory containing all files belonging in the distribution, including 0-length placeholders for the module build results.

Build notes

Directory names: Top-level temporary build directories are prefixed "aj-", so you can safely destroy any such directory or ignore it in CVS or the Eclipse package explorer. By default the build script puts them at the same level as other modules. Property names follow a similar convention; those prefixed "aj-" may be deleted at will, while "aspectj-" names are source directories which should never be deleted.

Version synchronization: Developers use the default "DEVELOPMENT" version unless doing or testing release builds. The build version is set in build-properties.xml and tracked in ../bridge/src/org/aspectj/bridge/Version.java which the build.xml init-version task generates from a template lib/BridgeVersion.java.txt using copy filters to set the build version and date. To avoid updating Version.java whenever build-properties.xml changes, a task src/org/aspectj/internal/tools/ant/taskdefs/VersionUptodate.java determines whether Version.java has the same version by scanning the source file. (Do not change the lines flagged in the template without also changing the scanning code in the task.)