Equinox p2 PDE Integration

Introduction

This page is intended to document changes required in the PDE component to support integration of p2 tooling into the platform.

These items should be addressed in the 3.4 time frame. The current priority is to make progress in all areas to support the smooth introduction of p2 tooling into the platform. P2 tooling must be able to work with PDE. More complete solutions can be looked afterwards.

Update Manager Tooling

Users will see little difference in UI of the update manager for 3.4. However, p2 will require additional work be accomplished by the update manager.

Site Editor

There already exists a site editor that allows update sites to be converted to the p2 equivalent. The site editor generates metadata for p2.

We want the ability to provide the metadata generator with 'advice'. This advice allows p2 to know more about how to install/launch IUs. For example, the start level could be specified, or a port to run on. We want to prompt for this information.

Feature Editors

Change tooling to build for P2.

PDE Launch Tooling

Old Way

PDE tooling would check if the launch uses the Update Configurator. If so, it is update manager aware. A platform.xml is written listing all of the bundles in the launch. This is the most common use case (90%).

If the launch does not use the Update Configurator, the bundles OSGi uses are determines from config.ini. Config.ini lists each bundle that should be run along with start levels. It is more flexible than the Update Configurator, but requires more effort to set up.

New Way

The launch could use the p2 way of doing things. This involves using p2 profiles which are managed by the agent. If p2 is running it needs to know about what is bundles are being run to be useful. PDE will therefore have to provide this information to p2. The p2 agent may be universal to the computer, managing all profiles. This will allow 'p2 self-hosting'. The p2 agent will be able to provide information about running/installed bundles and install bundles on-the-fly from the host.

There will also be a Simple Configurator. It will use bundles.txt to determine which bundles to launch in a similar way that the config.ini worked. This configurator will make it easier to accomplish this. It should be able to determine what is running/installed and what is needed according to the bundles.txt. The simple configurator will need information from PDE.

There will still be the ability (and use cases) to use config.ini to organize the OSGi launch.

There is improved API (FrameworkAdmin) to modify these files (config.ini, bundles.txt).

Target Provisioning

Currently PDE has the wizards to generate a target platform configuration by adding bundles/features from both the local file system and update sites. p2 needs the equivalent tool. PDE will need to understand more about profiles as it cannot make the same assumptions about the locations of files (target directory).