Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Equinox/p2/Getting Started for Releng

The Eclipse Ganymede (3.4) release introduces Equinox p2, a new platform for installing, managing, and updating Eclipse-based applications and extensions. p2 offers significantly improved functionality over the platform Update Manager used in previous releases. Leveraging this new functionality requires some changes for people building and assembling Eclipse-based applications and add-ons. This article helps buildmeisters and release engineers to get started with adopting p2. See also Equinox p2 Getting Started for an introduction to p2 from an end-user perspective.

Why do I need to make changes to adopt p2?

p2 offers significant advances over the Update Manager found in previous versions of the platform. Some advances include:

  • The ability to install complete Eclipse-based applications from scratch, above just augmenting and updating already installed applications.
  • The ability to install and manage an application from either inside the application or from another process.
  • The ability to install and manage artifacts other than plug-ins and features, such as launchers, root files such as licenses, configuration files, Java VMs, etc.
  • Dynamic discovery and high-fidelity resolution of software dependencies.

These advances require additional metadata about the software being installed above the information in the feature.xml and site.xml files used by Update Manager. Feature.xml files provide an incomplete picture of software dependencies - they are essentially a coarse-grained subset of the dependencies expressed in the plug-in manifest file (MANIFEST.MF). p2 metadata includes a complete description of these dependencies, allowing it to be 100% accurate about resolving dependencies at install-time. With p2, you can pick a single plug-in to install, and p2 will be able to compute the complete set of plug-ins and other artifacts required to satisfy the runtime requirements of that plug-in. To accomplish this, p2 needs to either obtain or create this high-fidelity dependency information at install-time.

Update Manager only supported adding additional content, or upgrading existing content, in an Eclipse-based application. It did not allow you to provision an entire application from scratch, including launchers and other files that were not plug-ins or features. p2 can install and update entire applications, including all these non plug-in/feature bits. To accomplish this, p2 needs to obtain or create the necessary metadata to reason about these artifacts and their dependencies.

The reason build and release engineering teams need to take extra steps to adopt p2 is to produce this p2 metadata that allows p2 to support this new level of functionality.

What do I need to do to adopt p2?

The following sections describe steps to adopting p2 depending on what kind of outputs your project produces.

Zips of plug-ins and features

If your project produces zips of plug-ins and features for consumption by others, no action is required. p2 provides a number of ways for an end-user to install such zips:

  • Drag into the "Software Updates" dialog in the UI
  • Unzip into the eclipse/dropins folder
  • Unzip directly on eclipse root directory (generally not recommended as it makes it difficult to distinguish added content from the base application).

However, when p2 encounters raw plug-ins and features, it needs to do some processing on the content to compute p2 metadata. This results in a slower experience for the end user when the content is first installed. You can optimize this by creating a p2 repository that contains your plugins and features. A p2 repository is created automatically if you export plug-ins and features from your IDE using the PDE plug-in export wizard. This adds a content.xml and artifacts.xml. p2 also provides a p2.generator Ant task or stand-alone application that can be invoked programmatically or from a build script to produce a p2 repository. See Equinox p2 Metadata Generator for more information about this generator application.

Update sites

If you currently produce an Eclipse Update Site (site.xml), there is also no action required. p2 can install plug-ins and features directly from existing update sites produced for earlier releases of the Eclipse Platform. However, p2 needs to produce its metadata on the fly when a simple update site is encountered.

Back to the top