17.1. Component Overview

This page intends to give a brief introduction to the GDA codebase from the perspective of the build.

GDA is a client/server application with separate products:

  • Server product - common across all beamlines, started by pointing to a beamline specific configuration

  • Client products - there is a separate product for each beamline (i.e. each beamline can be comprised of different plugins)

A “product” in this context refers to an Eclipse product which is a mechanism for packaging up Eclipse Plugins and Features into a platform specific standalone application.

Eclipse plugins and features are at the heart of Eclipse PDE (Plugin Development Environment). The minimal unit in PDE is the Eclipse Plugin. These are are OSGi bundles that may include additional plugin contributions (e.g. extension points). Eclipse features are used to group together plugins, fragment plugins, and possibly other features into a logical unit, typically this is the level that you would specify to ‘install’ (instead of a longer list of specific plugins). In most cases each of these components (plugin/feature/…) is represented by a single project in the IDE’s workspace.

The build consists of a set of components (as above) and a target platform. The target platform is the set of dependencies which our projects are built and launched against. The default case for PDE projects is that their development IDE is their target platform. It is much more common and sensible to define a specific target platform stored as part of the source code.

17.1.1. Repository structrure

GDA’s source projects are stored in a series of Git repositories hosted on Gerrit. Due to historical complexity there are multiple Git repositories containing projects, with no common structure. This complex layout requires a special tool for provisioning a workspace.

17.1.2. Java

GDA is primarily a Java project hence a JDK is required. The latest version of GDA is built and run with Java 11.

The definitive version of Java to used is defined by the DLS module system. There is a java module file for each version of GDA. For example:

module load java/gda919

would load the appropriate version of Java for compiling and running GDA 9.19.

These modules are documented on confluence.

For non DLS provisioning the user should ensure that a suitable JDK is present on their $PATH before attempting these steps.

Oomph will take on the role of managing the available JREs/JDKs and is configured with specific requirements where appropriate (although these are not always robost e.g. JDK 11 is a valid Java 1.8+ JDK).

17.1.3. Eclipse Installer (Oomph)

Oomph is the current recommended approach for installing the Eclipse IDE (and its variants) itself. It allows for very bespoke and customised workspace provisioning including preference recording, dynamic resolution of workspace projects and a caching technique (bundle pool) allowing many isolated IDEs and workspaces to be created without duplicating dependencies.

The general principle of Oomph is that it allows developers to provision a consistent development environment taking into account both project and personal preferences, with minimal effort. Oomph is based around three scopes:

  • Installation (IDE)

  • Workspace

  • User

A typical provisioning action involves creation of a new installation and workspace. Due to the bundle pool technology there is minimal overhead in creating a new installation per workspace. This has the advantage that development environments are isolated (e.g any different IDE plugins required/preferences are isolated to the specific provisioned environment).

For further details see Provisioning GDA.

17.1.4. Tycho (Maven)

Tycho is a set of Maven plugins designed for building Eclipse projects. It bridges the gap between PDE and Maven. The general idea is to use a manifest first approach whereby the existing OSGi/PDE metadata is used to define each project’s build and dependencies. Tycho builds are generally very different from “standard” maven projects in terms of project structure, lifecycle and dependency management. For example it generally is a bad idea to add dependencies to a Maven pom as the PDE infrastructure will not be aware of this causing mismatches between the workspace and the Maven build.

Similarly to PDE in the IDE, Tycho uses a set of p2 repositories (defined in a PDE Target file) to resolve the project dependencies against and fetches artifacts from these p2s to store in the local m2 cache. Tycho uses a Maven reactor build, with each PDE project (plugin, feature, etc.) being a module within the reactor. Another important feature of Tycho is the pomless functionality. This allows a minimal set of poms to define the build and list the included modules without each project itself having to maintain a pom which helps to cut down on duplication and additional maintenance of build files.

For further details see Building GDA.