Difference between revisions of "Equinox p2 PDE Integration"

Revision as of 16:18, 25 October 2007

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 at afterwards.

Update Manager Tooling

Users will see little difference in UI of the update manager for 3.4 - they will still develop in terms of features, etc. However, Update Manager will be implemented in terms of p2 under the covers.

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.

Install Handlers

Site Builders

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

See Bug 204347

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).

Simple solution that requires changes to PDE API. See Bug 207503 for proposed changes. The equinox provisioning wizard would allow the user to select a p2 provisioned install (containing both the bundles.txt config data and the launcher data). The wizard would use the bundles.txt to create a list of plug-ins to add to the target. The PDE API would be changed to allow plug-in files to be returned as locations as well as directories (which are already supported). The plug-ins would be added to the target.

What should the wizard be called? If p2 is being added under the covers, what should we call the wizard which will be seen by users?

What should the wizard look like? Perhaps something like the new JRE wizard page. You can select a directory. The directory will be searched for the proper config and launcher data. If there is a problem this can be displayed to the user. If the directory is valid, we could load the list of bundles from the bundles.txt and display this information in a table. When the user hits finish, we add those bundles to the target.

What to do if the bundles config data and launcher data are stored in separate directories? The agent allows installs to have separate directories for installing the launcher and storing the bundles, how will this affect the wizard?

Is the PDE support too minimal? PDE Target support feels "minimal". PDE only supports one "development target". The pref page for managing this is somewhat ugly, as it shows a flat list of all bundles to choose from that come from different targets. Although one can display bundles grouped by location, in the p2 world, that is also insufficient as bundles can be located anywhere. If we want to be able to develop against and launch p2 provisioned targets, it feels like PDE will need better "target management" support. I.e. be able to persist descriptions of mutliple targets, choose between them for development time buildpaths and launching. We can do something simple to get started with p2, but it feels like there's higher level issues we need to consider .