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

Difference between revisions of "Equinox p2 PDE Integration"

(Target Provisioning)
Line 4: Line 4:
 
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.
 
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 ==  
+
== 3.4 Plan ==  
  
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.
+
1) Support p2 metadata creation during site building, feature building, plugin export, product export
 +
2) Allow target provisioning from p2 repositories
 +
3) Read p2 bundles.txt data on startup to build target platform (completed 3.4 M4)
 +
4) Write p2 bundles.txt data on Eclipse launches (completed 3.4 M5)
 +
5) Write p2 bundles.txt data on OSGi launches with start level data (completed 3.4 M5)
  
=== Site Editor ===  
+
== Metadata Creation ==  
  
There already exists a site editor that allows update sites to be converted to the p2 equivalentThe site editor generates metadata for p2.
+
PDE Build will have support to generate p2 metadata in 3.4 M5PDE UI must update the site builder, feature builder, plugin export, and product export tooling to invoke the PDE Build support.
  
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.
+
The properties that must be set are as follows:
 +
generate.p2.metadata = true
 +
p2.metadata.repo = file://${buildDirectory}/repo
 +
p2.artifact.repo = file://${buildDirectory}/repo
 +
p2.flavor = tooling
 +
p2.publish.artifacts = false
  
=== Feature Editors ===
+
There will be no changes to the editors UI.  Metadata generation will be transparent to the user and always take place in a p2 hosts.  We may add an option in the preferences to turn off metadata generation as it may cause problems for certain RCP development scenarios.
  
Change tooling to build for P2.
+
== p2 Target Provisioning ==
  
=== Install Handlers ===
+
PDE UI added an extension point in the 3.3 timeframe that allows implementors to add new target provisioners to the list available when pressing the Add... button on the Target Platform preference page.  The extension point allows a wizard page contribution and expects a directory to be returned.  This directory should contain any new bundles that should be added to the target platform.
  
=== Site Builders ===
+
Currently the target provisioner has support for loading from the file system and update sites.  The file system option will remain the same.  The update site provisioner is very limited in features and will be removed.  The new provisioner, which will support p2 repositories, will also be able to provision from update sites using support already available in p2.
  
== PDE Launch Tooling ==
+
We are hoping to reuse viewers and other UI support from other areas of p2.  The UI will allow users to browse through the features/groups of a repository (or update site) and select what to add to the target.  The bundles/artifacts associated with the selected features/groups will be downloaded to a directory and this directory will be returned to PDE UI.
  
=== Old Way ===
+
Code for this feature will be added in org.eclipse.equinox.p2.target.
  
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 launchThis is the most common use case (90%).
+
There already exists a site editor that allows update sites to be converted to the p2 equivalentThe site editor generates metadata for p2.
  
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.
+
We want the ability to provide the metadata generator with 'advice'.  This advice allows p2 to know more about how to install/launch IUsFor example, the start level could be specified, or a port to run onWe want to prompt for this information.
 
+
=== 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 usefulPDE 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 workedThis 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 [https://bugs.eclipse.org/bugs/show_bug.cgi?id=204347 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).
+
== Build Target Platform from bundles.txt ==
  
Simple solution that requires changes to PDE API.  See [https://bugs.eclipse.org/bugs/show_bug.cgi?id=207503 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.
+
See [Bug 209260|https://bugs.eclipse.org/bugs/show_bug.cgi?id=209260]
 +
Completed for 3.4 M4
  
What should the wizard be called?
+
PDE will read bundles.txt on startup and resolve the target platform using the information found.
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?
+
== Write bundles.txt on Launch ==
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?
+
See [Bug 210539|https://bugs.eclipse.org/bugs/show_bug.cgi?id=210539].
The agent allows installs to have separate directories for installing the launcher and storing the bundles, how will this affect the wizard?
+
Completed for 3.4 M5
  
Is the PDE support too minimal?
+
When launching using an Eclipse runtime launch configuration or an OSGi launch configuration in a p2 host, a bundles.txt file will be written out in the same location as the config.ini.  The generated config.ini will contain the property org.eclipse.equinox.simpleconfigurator.configUrl pointing to the location of the bundles.txt.  The bundles.txt will contain an entry for each bundle in the launched runtime along with a start level and auto-start settingExcept for a few hard coded exceptions, Eclipse runtime launches will have every bundle's start level set to the default.  When launching OSGi, the start level and autostart settings are taken from the launch configuration.  There is currently no support for users to change whether bundles.txt is generated or where the file is placed.
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 launchingWe can do something simple to get started with p2, but it feels like there's higher level issues we need to consider .
+

Revision as of 12:32, 22 January 2008

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.

3.4 Plan

1) Support p2 metadata creation during site building, feature building, plugin export, product export 2) Allow target provisioning from p2 repositories 3) Read p2 bundles.txt data on startup to build target platform (completed 3.4 M4) 4) Write p2 bundles.txt data on Eclipse launches (completed 3.4 M5) 5) Write p2 bundles.txt data on OSGi launches with start level data (completed 3.4 M5)

Metadata Creation

PDE Build will have support to generate p2 metadata in 3.4 M5. PDE UI must update the site builder, feature builder, plugin export, and product export tooling to invoke the PDE Build support.

The properties that must be set are as follows: generate.p2.metadata = true p2.metadata.repo = file://${buildDirectory}/repo p2.artifact.repo = file://${buildDirectory}/repo p2.flavor = tooling p2.publish.artifacts = false

There will be no changes to the editors UI. Metadata generation will be transparent to the user and always take place in a p2 hosts. We may add an option in the preferences to turn off metadata generation as it may cause problems for certain RCP development scenarios.

p2 Target Provisioning

PDE UI added an extension point in the 3.3 timeframe that allows implementors to add new target provisioners to the list available when pressing the Add... button on the Target Platform preference page. The extension point allows a wizard page contribution and expects a directory to be returned. This directory should contain any new bundles that should be added to the target platform.

Currently the target provisioner has support for loading from the file system and update sites. The file system option will remain the same. The update site provisioner is very limited in features and will be removed. The new provisioner, which will support p2 repositories, will also be able to provision from update sites using support already available in p2.

We are hoping to reuse viewers and other UI support from other areas of p2. The UI will allow users to browse through the features/groups of a repository (or update site) and select what to add to the target. The bundles/artifacts associated with the selected features/groups will be downloaded to a directory and this directory will be returned to PDE UI.

Code for this feature will be added in org.eclipse.equinox.p2.target.

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.

Build Target Platform from bundles.txt

See [Bug 209260|https://bugs.eclipse.org/bugs/show_bug.cgi?id=209260] Completed for 3.4 M4

PDE will read bundles.txt on startup and resolve the target platform using the information found.

Write bundles.txt on Launch

See [Bug 210539|https://bugs.eclipse.org/bugs/show_bug.cgi?id=210539]. Completed for 3.4 M5

When launching using an Eclipse runtime launch configuration or an OSGi launch configuration in a p2 host, a bundles.txt file will be written out in the same location as the config.ini. The generated config.ini will contain the property org.eclipse.equinox.simpleconfigurator.configUrl pointing to the location of the bundles.txt. The bundles.txt will contain an entry for each bundle in the launched runtime along with a start level and auto-start setting. Except for a few hard coded exceptions, Eclipse runtime launches will have every bundle's start level set to the default. When launching OSGi, the start level and autostart settings are taken from the launch configuration. There is currently no support for users to change whether bundles.txt is generated or where the file is placed.

Back to the top