Build and Test AspectJ

This describes how to build and test AspectJ for developers working on source code for AspectJ. It covers building with Ant or Eclipse and testing with JUnit and the harness used for compiler tests. For information on how the build works and how to debug failed builds, see readme-build-module.html.

Quick start
Requirements
Standard builds

Building using Ant
Building with Eclipse
Running the Ant build scripts from Eclipse
Using Eclipse to compile but Ant to assemble

Running build products
1. Running the compiler, browser, or harness from the command-line
2. Running the compiler, browser, or harness from Eclipse
3. Running Ant-built jars from Eclipse
Testing AspectJ
1. Running JUnit tests in Eclipse
2. Running JUnit tests from the command-line without Eclipse
3. Running JUnit tests from Ant without Eclipse
4. Using the test harness to run compiler tests
Releases
1. Release builds
2. Release preconditions and testing
3. Release completion
Build Problems

Quick start

This is a minimal introduction to building and testing AspectJ.

Command-line users use CVS to check out something like this:

  export CVS_ROOT=":pserver:anonymous@dev.eclipse.org:/home/technology"
  cvs co org.aspectj/modules

If using Eclipse, check out the subdirectories of org.aspectj/modules as Java projects. Skip modules aspectj-attic and (unless running compiler tests) tests and most testing* modules. Do not skip testing-utils, which is used by other modules.

Build an AspectJ distribution:

  cd org.aspectj/modules/build
  ../lib/ant/bin/ant -f build.xml

To speed the build, Eclipse users can adopt the Eclipse-produced .class files:

  ../lib/ant/bin/ant -f build.xml -Dbuild.config=useEclipseCompiles

Install the distribution (e.g., into build/../aspectj-install):

  java -jar ../aj-build/dist/aspectj-DEVELOPMENT.jar

You can skip the GUI by specifying an existing, empty writable target directory using -to {targDir}:

  java -jar ../aj-build/dist/aspectj-DEVELOPMENT.jar -to .

Test it by running the build script in the examples directory:

  cd ../aspectj-install/doc/examples
  ../../ant/bin/ant

This should build and run the spacewar example.

Requirements

To build requires only the AspectJ project modules. All necessary libraries and tools are in the lib directory. For command-line users, that usually means checking out the modules directory:

   export CVS_ROOT=":pserver:anonymous@dev.eclipse.org:/home/technology"
   cvs co org.aspectj/modules

Eclipse users should check out subdirectories of org.aspectj/modules as a Java project.

Not all modules are required. The aspectj-attic module only has old code, and the tests and testing-* modules are only needed to run tests.

Standard builds

Building using Ant

To do a build, use Ant to run build.xml from this build directory. To run Ant, use the project's ../lib/ant scripts and libraries, not your own. The default target builds the AspectJ distribution; see the build.xml for other targets. Consider defining the following flag properties:

Property Meaning

module.name To build any module (esp. those not directly supported by a target), use the "any-module" target and define the module name.

check.build.jar any value cause build to fail if lib/build/build.jar is out of date. (This is a built archive of the build module to avoid bootstrapping.)

build.config override default configuration in build.xml. Significant values include "verbose" for more output and "useEclipseCompiles" to assume that Eclipse has compiled modules into their bin directories, and just assemble those classes.

Property	Meaning
module.name	To build any module (esp. those not directly supported by a target), use the "any-module" target and define the module name.
check.build.jar	any value cause build to fail if `lib/build/build.jar` is out of date. (This is a built archive of the build module to avoid bootstrapping.)
build.config	override default configuration in build.xml. Significant values include "verbose" for more output and "useEclipseCompiles" to assume that Eclipse has compiled modules into their bin directories, and just assemble those classes.

For example, to build everything into a release bundle, with verbose logging

  cd modules/build
  ../lib/ant/bin/ant

To build only the asm module (and any modules it requires):

  cd modules/build
  ../lib/ant/bin/ant -f build.xml any-module -Dmodule.name=asm

To build the test harness into ../aj-build/jars/testing-drivers-all.jar:

  cd modules/build
  ../lib/ant/bin/ant -f build.xml build-testing-drivers

Building with Eclipse

As mentioned above, the modules are Eclipse Java projects, so once checked out, they should build as-is. That will enable you to run the compiler or test harness from within Eclipse (see below), but it will not build the AspectJ release as Ant does.

Running the Ant build scripts from Eclipse

When running Ant from Eclipse, be sure to replace the Eclipse Ant libraries with ours. In the Ant configuration, remove all jars specified by Eclipse and add all the libraries in ../lib/ant/lib as well as in ../lib/junit. (Do not add ../lib/build/build.jar, which is added via a taskdef declaration.)

If you find on rebuilding that the build products are not being regenerated, you may need to manually delete them or restart eclipse (the files are not being closed); see readme-build-module.html for more information.

Using Eclipse to compile but Ant to assemble

Assuming Eclipse is compiling the AspectJ modules successfully, you can use Ant to assemble the eclipse-build .class files into a product by including useEclipseCompiles in the build.config variable as described above. That reduces the build process to product assembly, which can be completed in a couple minutes. (And of course you can run Ant from Eclipse as described above.)

Running the compiler, browser, or harness from the command-line

The build produces jar files in ../aj-build/jars/, some of which have manifests specifying the main class, so they can be run using java -jar {file} {arguments}.

To run the compiler from the command-line, use the ajbrowser jar file:

   java -jar aj-build/jars/ajbrowser-all.jar {compile arguments}

This will run ajbrowser if you provide no arguments or only (unflagged) .lst file arguments. To run the test harness, use the testing-drivers jar file:

   java -jar aj-build/jars/testing-drivers-all.jar tests/ajcTests.xml ...

Running the compiler, browser, or harness from Eclipse

To run things within Eclipse, create a run configuration from the defining module using the main class:

Program Module Main

AspectJ compiler org.aspectj.ajdt.core org.aspectj.tools.ajc.Main

AspectJ browser ajbrowser org.aspectj.tools.ajbrowser.Main

Test harness testing-drivers org.aspectj.testing.drivers.Harness

Program	Module	Main
AspectJ compiler	org.aspectj.ajdt.core	org.aspectj.tools.ajc.Main
AspectJ browser	ajbrowser	org.aspectj.tools.ajbrowser.Main
Test harness	testing-drivers	org.aspectj.testing.drivers.Harness

Running Ant-built jars from Eclipse

You can run build products (built jars) from Eclipse in two ways:

Put them on the classpath of some run configuration
Select the jar files and right-click to "open with default editor" (assuming your system is configured to run .jar files)

You might do this to run the installer or test the browser as built. However, doing so might prevent those jar files from being recreated in the next build. It appears that sometimes these jar files are not close during the Eclipse session, which means they cannot be overwritten in new builds, even those run from a different Ant process. If you find that builds are silently failing, try deleting the build products.

Testing AspectJ

Each module has a tree of JUnit tests in the testsrc directory. These parallel the src directories and contain roll-up suites for each package ({module}/testsrc/{packagePath}/{package}Tests.java) and for the module as a whole ({module}/testsrc/{module}ModuleTests.java).

The AspectJ project also has additional custom tests in the tests module, mainly the compiler tests run by the harness in ajcTests.xml. It is important to run these additional compiler tests (not covered by the JUnit suite) before and after any change to the compiler.

Running JUnit tests in Eclipse

JUnit tests may be run under eclipse by selecting any JUnit source file and creating a run configuration for it. To run all the JUnit tests, use Ant to "build" ../tests/junitModules.xml. This file uses the eclipse module bin directories as its classpath, so it will not work for someone not compiling with Eclipse.

Running JUnit tests from the command-line without Eclipse

The AspectJ project committers do not do this, but it should work fine. The trick is to build the modules with their associated test code (which happens by default) and put the resulting jars on the classpath with the JUnit harness.

Running JUnit tests from Ant without Eclipse

This entails editing ../tests/junitModules.xml to use a classpath containing the built module jars as described above. [todo: update junitModules.xml with non-eclipse variant]

Using the test harness to run compiler tests

The build-testing-drivers target builds a single jar with the AspectJ binaries and a test harness as the main class. It reads test suite files like ../tests/ajcTests.xml; use the -help flag to see available options. For more information, see ../tests/readme-tests-module.html.

Releases

Release builds

Committers do official release builds to create the distribution released in binary form from the web site. 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. Do not run using the build.config value useEclipseCompiles, because this will include testing classes in the release libraries. See Version synchronization below for more details on how the version is updated.

Release preconditions and testing

Normally, we do releases only after fixing all high-priority (P1 and P2) bugs in the bug database ( All open AspectJ bugs with P1 and P2). For bug fixes, associated tests in tests/ajcTestsFailing.xml are fixed and moved to tests/ajcTests.xml.

Before a release, run the following tests using a Java 1.3 VM (the minimum required by the AspectJ tools):

JUnit tests. Run these before the final build using tests/junitModules.xml (which runs all the modules/{module}/testsrc/{module}ModuleTests.java).
All compiler tests in tests/ajcTests.xml and tests/ajcTestsFailing.xml. Run these before the final build using the test harness, as follows:
```
  cd tests/
  java -jar {..}/testing-drivers-all.jar ajcTests.xml -release 
```
The -release option skips tests marked purejava or knownLimitation and only emits one-line results for each test:
```
PASS one test identifier()
FAIL another test identifier()
...
```
(Use -help on the harness to see the full definition of the -release alias.) Run with and without the -emacssym option, saving the output to the appropriate subdirectory of the org.aspectj/releases directory with the name ajcTests-result-{version}.txt or ajcTests-result-{version}-emacssym.txt.
Compare results with a prior release or test run using TestDiffs:
```
  set CLASSPATH="{..}/testing-drivers-all.jar"
  java org.aspectj.testing.util.TestDiffs {first-run}.txt {second-run}.txt
```
This will generate lists of tests fixed, broken, missing, or added. For a release, no tests from ajcTests.xml should be broken, and missing tests (those in the first run absent from the second run) should be justified (usually the test was removed as invalid). A test will show up as missing from the first run and added to the second run if it is renamed between runs. For a final release, no test should be FAIL unless it is deferred (including those from ajcTestsFailing.xml).
For more information, see the instructions for building and running the test harness and the tests ../tests/readme-tests-module.html.
Examples. Run these on the built/installed release. The following should build and run the spacewar example:
```
    cd {aspectj-install}/doc/examples
    {ant 1.5.1} -f build.xml
```
Also run 2-3 other targets from Ant and some examples directly:
- The target all runs all examples, and nonGui runs those that do not require manual operation;
- The targettracing-bc does bytecode weaving;
- Run some of the compiled examples in a 1.1 VM (the minimum required for running AspectJ code).
This quick test verifies that the aspectjtools.jar and aspectjrt.jar are installed and have a matching version, that the examples actually compile and run, etc.
If there are any bugs which are closed with this release but which do not have an automated test case run using JUnit or the harness, those bugs should be manually tested against the release.
Any other tests warranted by release objectives. E.g., make sure it works as expected for any demos or for any clients (e.g., Emacs, AJDT).

Some failures with past releases to consider checking:

debug info not included in .class files
Ant variables not filtered into doc files (e.g., ant-tasks.html)
Manual dates not changed in docs or readme
Inconsistent version information between runtime and tools classes

Release completion

When the release build is accepted, tag the tree with the release version so others can do diffs or create patches based on the release code. E.g., from the command line:

   cd org.aspectj/
   cvs tag -R -c v1_1_0

Pushing the release out to the web involves manually updating aspectj-home/ with the release files (and documentation, if it is not a preview release), verifying the downloads and pages, and sending any release notifications. Save the release installer, test results, and any notes about deferred bugs or tests in org.aspectj/releases/aspectj-{version}/.

Build problems

Some build problems and fixes encountered in the past:

If your compiles fail because Ant cannot find javac, put the JDK bin directory on your PATH and/or define the JAVA_HOME environment variable. Ant requires the path to the javac executable when the BuildModule taskdef runs. I think it either gets it from $JAVA_HOME or if the bin directory is on the PATH.
If using an IBM JDK at version 1.4 or higher within Eclipse, then the default value of JRE_LIB will point to the jar file "core.jar." Unlike the Sun JDK, IBM does not package the full runtime into a single jar ("rt.jar"), but instead has multiple jar files. Since core.jar does not contain the graphics libraries, several of the AspectJ projects will fail to build as checked out of CVS - there are missing dependencies on AWT and swing. The solution is to add graphics.jar to the project classpaths... BUT if this is added as an ordinary (external jar), then the main ant build script will pick up the contents of graphics.jar and include it in the aspectj distribution (obvious clue, the size of the built aspectjtools.jar doubles to about 10MB). Instead, from the Java Build Path properties page of the project, select "Add Library" and add the JDK library. You now have to remove the JRE_LIB entry from the project or Eclipse complains about duplicate jar files in the path.