EMF-IncQuery Automatic Build Configuration

The EMF-IncQuery build system

EMF-IncQuery uses Maven/Tycho for continous integration builds.

Project structure

  • plugins/*: The various plug-ins projects EMF-IncQuery project consists of.
  • features/*: Installable feature projects
  • tests/*: Plug-ins related to testing EMF-IncQuery. Does not include tests with external dependencies (e.g. school)
  • releng/org.eclipse.viatra2.emf.incquery.licence.feature: special licence feature for the update site to avoid storing the EPL licence multiple times
  • releng/org.eclipse.viatra2.emf.incquery: The root project of the build, used as parent project for configuration inheritance, and it contains a lists of projects to build.
  • releng/org.eclipse.viatra2.patternlanguage.update: Update site project - the build creates a p2 repository from this project.

Adding a new project to the build

There are two important things to configure for adding a new project to the build:

  1. In order to technically build the project, a build configuration needs to be created (and registered in the root project).
    1. This consists of a single pom.xml file in the project root.
    2. And a module declaration in the parent pom.
  2. Add the created feature to either an existing or a new feature
    1. If an existing feature is used, the feature.xml has to be extended with the id of the new project.
    2. If a new feature is created, this feature is required to be registered both in the root project and in the update projects' category.xml file.
    3. In both cases, don't forget to add the source plugin to the SDK or another Sources feature.

An example commit for executing all these steps (with the creation of a new project) is: https://github.com/ujhelyiz/EMF-IncQuery/commit/4b523260c94ddb2605ce1088... (Note that the addition of a source plugin is not included).

Defining the build configuration for a plug-in project

A project needs to have a pom.xml file in the project root for the build configuration. In most cases, this build configuration is very simple, as all required configurations are inherited either from the project type (Eclipse plug-in project) or the root project. Basically, there are two configuration types used in the project:

  1. Projects with xtend files (e.g. the org.eclipse.viatra2.emf.incquery.tooling.generator project)
  2. Projects without xtend files (e.g. the org.eclipse.viatra2.emf.incquery.base project)

To create such a configuration file for a new project, the recommended solution is to copy an existing corresponding project configuration, and replace the plug-in identifier.

Warning! If a project for any reason uses a different version number then the base IncQuery project (currently 0.7.0.qualifier), it is important to add the version information to the project, replacing '.qualifier' with '-SNAPSHOT' (currently 0.7.0-SNAPSHOT).

Additionally, the new project needs to be added to the parent project (org.eclipse.viatra2.patternlanguage.update):

The pom.xml file contains a module section where a list of submodules are presented - it needs to be extended with a new submodule describing the project location.

Adding the plug-in to an existing feature

The existing feature.xml file has to be extended with the new plug-in as a contained plug-in id.

Additionally, a source plug-in might need to be added to (a possibly different feature). The id of the source plug-in is: «plugin.id».source. The feature.xml editor reports warnings as such projects are non-existent in the project; however they are created during the build and included.

Currently most source plug-ins are added only to the SDK bundle, with the notable exceptions of runtime bundles that are added to the runtime features.

Adding the plug-in to a new feature

Creating a new feature project works similarly to creating a new plug-in project, but the feature builder pom.xml files are more simple. The recommended way of creating a new feature is to copy and existing one, and modifying the identifier, descriptions and contained plug-ins (and possibly features). The feature also needs to be registered into the root projects module section.

Additionally, this feature needs to be added to the update site. For this reason, the feature needs to be registered in the category.xml file stored in the update site project - the category.xml file has a form-based editor.