Page History

...

The basic structure of the POM files is the same for both, the pragmatics and semantics repository, and can be seen below:

Each plug-in and feature has a corresponding (usually rather small) POM file. The POM files in the features and plugins directories know about the different features and plug-ins. The parent POM file, which all other POM files copy basic configuration from, knows about the feature and plug-in POM files, as well as about every kind of build configuration we have (for building the pragmatics repository, for building the KWebS product, etc.). In addition, the build directory also contains a bunch of subdirectories . These also contain housing POM files specialized for building the P2 repositories necessary to publish our Eclipse featuresthat produce our p2 repositories and our products.

Using the KIELER Maven Build

Using the KIELER Maven build requires knowledge about two aspects: necessary configuration / required libraries and invoking Maven.

Necessary Configuration

KIELER needs to be built against a P2 repository generated from our Eclipse reference installation. The path to this repository is found in the parent POM file and must be changed if the repository location changes. Also, when changing the reference installation, the repository has to be updated using the following magic command (adapted accordingly):

java -jar eclipse_3.8/plugins/org.eclipse.equinox.launcher_*.jar \
-application org.eclipse.equinox.p2.publisher.FeaturesAndBundlesPublisher \
-metadataRepository file:/home/java/repository/juno382 \
-artifactRepository file:/home/java/repository/juno382 \
-source /home/java/eclipse_3.8/ \
-publishArtifacts

Invoking Maven

To actually build KIELER once all preliminaries are donethings: a working Maven installation (d'oh...) and knowledge about how exactly to trigger a build. We leave the former to you, but the latter is what this section is about.

To actually build KIELER, navigate to the /build/de.cau.cs.kieler.parent directory and run the following command line:

. /home/java/java-env            # Only necessary when working on our servers
mvn clean package -P <profile>   # For a list of available profiles, see parent pom.xml

Once Maven has finished, the different build artifacts may be found in the /build/de.cau.cs.kieler.*<profile>.repository/target directories. The following build profiles are available in the KIELER Pragmatics repository:

• klighdning – Builds a standalone version of the KLighDning server, based on the current nightly pragmatics update site.
• kwebs – Builds a standalone version of the KWebS server, based on the current nightly pragmatics update site.
• pragmatics – Builds a p2 repository that contains our pragmatics features. This is what would usually be pushed online for people to download as our nightly pragmatics build.
• ptolemy-rcp – Produces a standalone version of our Ptolemy Model Viewer, based on the current nightly build pragmatics update site.

The following build profiles are available in the KIELER Semantics repository:

What to Be Aware of

There are some things that people need to be aware of to keep the build files in a valid state.

1. Eclipse metadata and POM files are not synchronized. Thus, if the version of an Eclipse plug-in changes, its pom.xml needs to be updated accordingly.
2. The repository POM directories contain product files and product icons. These are copies of the files found in the corresponding branding plug-ing (such as de.cau.cs.kieler.core.product) and have to be manually synchronized.

The Curious Case of Building the KLay Library

...

1. .

...

1. Set the PRODUCT environment variable to point to a complete installation of KIELER. You can get one by using the automatic Maven build.
2. Run Ant on the build.xml file. This will produce both versions of the KLay layout library.

Continuous and Nightly Builds

There are basically three four different kinds of build plans for each of the KIELER projects:

1. Continuous Plugins – Compiles the plug-ins and runs the unit tests on them. None of the compiled artifacts are published anywhere (in fact, no update site or product is even produced). This plan is triggered by pushing stuff into the repositories, giving early feedback regarding whether committed changes break anything.
2. Nightly Product – Compiles the plug-ins and assembles <Product> – Assembles distributable product files and/or update sites. Distributable files are published in the nightly build directory /home/kieler/public_html/files/nightly. Update sites are published in /home/kieler/public_html/updatesite/nightly. This plan is These plans are run once every night.
3. Nightly Rating – Compiles the plug-ins and runs our code quality rating doclet on them. The result is a website published at /home/kieler/public_html/rating. This plan is run once every night.
4. Release Builds – Continuous builds of release branches once a release is imminent. These usually run whenever changes are pushed into the repository. All release builds are placed in a special Bamboo project calles KIELER Releases.

The Semantics project has an additional build plan:

...

Our automatic builds produce a bunch of so-called artifacts: redistributable applications as well as a number of update sites. This table lists all artifacts, the project or repository they belong to, the build file responsible for producing them, the Bamboo build plan that builds them, and the directory they are finally placed in.