Build System

WPI Suite TNG uses Ant to build projects, following the system described on this page. When using Eclipse to run the software, Eclipse's built-in build system is used, but it is configured to use the Ant scripts when necessary. The build scripts should be able to run without an Eclipse installation, such as in an automated build system.

Usage

Install Ant, then run one of the following commands from a terminal

From the repository root

ant dist

Create everything necessary for deployment/release of WPI Suite TNG. This will create a "dist" directory containing a WAR file that can be deployed on a Tomcat server, a runnable JAR for Janeway, and module JARs for Janeway. If you're trying to deploy WPI Suite in a production environment, this is all you need.

ant compile

Compile all Java code and copy JARs to appropriate places in order to run WPI Suite in a debug environment.

ant clean

Remove all generated resources, including the dist directory and .class files.

ant test

Run all JUnit tests. If you're doing this on Jenkins, you should probably use ant clean test to make sure your old builds aren't interfering with anything. Another trick (on Linux) is to use ant test 1>/dev/null - If nothing is printed out, all of the tests passed since failures are printed to stderr (1>/dev/null hides stdout).

From a project directory

Besides any targets defined in the project's buildfile, you should be able to use these targets that all projects inherit

ant test.single

Run tests only for this project

ant compile.deps

Compile this project and any dependencies

ant clean.deps

Clean this project and any dependencies

How it works

If you are unfamiliar with Ant, the basic idea is that you specify a "target" and define the necessary steps to do what's necessary for that target. Targets can depend on other targets, and Ant will fulfill dependencies in the right order for whichever target you're trying to run. For example, you might have a "compile" target which calls the javac compiler in order to produce bytecode that you can actually run.

To summarize the article linked in the intro, each project has its own build.xml file. Project dependencies are defined in a dependencies.xml file. The root build.xml uses dependencies to call project build.xml files in the right order. For example, Janeway depends on Network, so Network must be built beforehand. Projects import build-common.xml, which lets them inherit some functionality and global property definitions. Project buildfiles should override some of the targets specified in build-common.xml.

Adding a module to the build system is covered on the Creating a New Module Project page. For most projects, this will boil down to copying an existing module's buildfile, replacing some names, and telling Eclipse to use it to build JARs into the right places.

Here are the relevant build files and DefectTracker's build.xml as an example:

• https://github.com/fracture91/wpi-suite-tng/blob/master/build.xml
• https://github.com/fracture91/wpi-suite-tng/blob/master/build-common.xml
• https://github.com/fracture91/wpi-suite-tng/blob/master/dependencies.xml
• https://github.com/fracture91/wpi-suite-tng/blob/master/DefectTracker/build.xml

Note that configuration options will need to be duplicated between Eclipse's project settings and the buildfile. For example, project dependencies are specified in both dependencies.xml and your Eclipse project settings. If your Eclipse classpath uses some shared JAR (say, Gson) then you need to make sure to compile with that JAR on your classpath in the buildfile.