17.4. Target Platform

The target platform is a fundamental component of the PDE environment.

A target platform defines the plugins for which the workspace will be built and against which the built application will be run.

This page covers the target platform concept in relation to the GDA and Dawn build: For a more generic overview see [here] (https://github.com/eclipse-pde/eclipse.pde/blob/master/docs/Target_Definitions.md).

17.4.1. Introduction

Target platforms are traditionally specified by a .target file. This file is composed of “locations” of different types which define the target platform. Although several location types are available, we need only focus on two types:

  • Software site - consume installable units from a p2 repository

  • Maven - consume direct Maven dependencies

Generally the “core” target platform for a PDE project is the version of the Eclipse runtime that the project is targeting, for example Eclipse 2022-12. Other custom dependencies may also be included.

Target platform components must be OSGi bundles to allow them to be deployed in the Equinox based runtime. Historically this has caused confusion and required extra work as many third party libraries are not built as OSGi bundles.

17.4.2. Maven support

Eclipse m2e (Maven support for Eclipse) supports a Maven target type for PDE. This allows for direct Maven dependencies to be included in the target platform. This is a significant improvement to PDE which widens dependency availability. Previously, all dependencies were only available via a p2 repository.

The Maven mechanism also provides support for automatically wrapping dependencies into OSGi bundles if they are not already so wrapped.

17.4.3. Oomph

One of the specialities of the GDA workspace is dynamic import of a set of projects into the workspace. This is achieved using Oomph’s modular targets (aka “targlets”). These work by specifying

  • a set of requirements (e.g. uk.ac.diamond.daq.server.feature),

  • a set of source project locations,

  • and a list of p2 repositories.

The requirements are then calculated and projects imported into the workspace where possible, or otherwise obtained from the list of p2 repositories.

This targlet based mechanism is more flexible than .target files, however Tycho does require a .target file. Therefore Oomph supports generation of an appropriate target file.

Note that targlets also support composition. This allows a specific target file, containing for example Maven dependencies, to be included in the targlet’s resolution context.

17.4.4. GDA Target platform

../_images/oomph-modular-target.png

The above image shows a section of the Oomph setup file, where the modular targets are defined.

There are several modular target entries in the file. At resolution time all modular targets are merged together, so the separation here is mostly for presentation.

Focusing on the modular target expanded in the image, one can see that it is composed of several other target platforms:

  • Maven Public

  • Maven Internal

  • JustJ

  • Legacy Dependencies from Eclipse Orbit

These are references to separate .target files that are present in the workspace. In addition to this there is a list: “P2 Repositories” where dependencies are dynamically satisfied, in contrast to the static nature of the target files.

17.4.5. Changing the target platform

The generally recommended approach for adding/managing dependencies is to use Maven dependencies. However there are some exceptions to this which are discussed first.

17.4.5.1. Updating Eclipse platform version

The Eclipse platform is sourced from a p2 repository in the list, for example: https://download.eclipse.org/releases/2022-09.

To test with a newer/different version,

  • change this URL accordingly,

  • save the file,

  • and run Help -> Perform Setup Tasks.

This update will instruct Oomph to recompute the dependencies of the workspace and download requirements from the new p2 repository.

Note that there are likely to be other dependencies (which may derive from other p2s, or Maven dependencies) which will need to be changed.

17.4.5.2. Dependencies from p2 repositories

Some other components are consumed from p2 repositories, e.g. Nebula. To determine if this is the case, look for the dependency in the list. The process for updating these is the same as the Eclipse version above.

17.4.5.3. Maven Dependencies

Many of the GDA specific dependencies are consumed directly as Maven dependencies. There are two files in the workspace to support this maven.public.target and maven.internal.target. Any dependencies available from Maven central should be defined in the “public” file. The “internal” file is for dependencies only available on Diamond’s internal Maven repository.

  1. Open maven.public.target or maven.internal.target and wait for it to resolve (see progress view)

  2. Edit one of the existing Maven locations, or create a new one if the categories do not align

  3. Add the new dependency using its Maven coordinates

  4. Choose finish

  5. Save the target file

  6. Perform setup tasks

Note that no changes are actually made to the active target definition until Setup Tasks are performed.