Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Equinox p2 PDE Integration"
| Line 2: | Line 2: | ||
This page is intended to document changes required in the PDE component to support integration of p2 tooling into the platform. | 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. | + | 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 = | + | == 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. | 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 == | + | === 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. | There already exists a site editor that allows update sites to be converted to the p2 equivalent. The site editor generates metadata for p2. | ||
| Line 14: | Line 14: | ||
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. | 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 == | + | === Feature Editors === |
Change tooling to build for P2. | Change tooling to build for P2. | ||
| − | == Install Handlers == | + | === Install Handlers === |
| − | == Site Builders == | + | === Site Builders === |
| − | = PDE Launch Tooling = | + | == PDE Launch Tooling == |
| − | == Old Way == | + | === 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%). | 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%). | ||
| Line 30: | Line 30: | ||
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. | 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 == | + | === 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. | 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. | ||
| Line 40: | Line 40: | ||
There is improved API (FrameworkAdmin) to modify these files (config.ini, bundles.txt). | There is improved API (FrameworkAdmin) to modify these files (config.ini, bundles.txt). | ||
| − | = Target Provisioning = | + | == 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). | 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). | ||
Revision as of 17:27, 19 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.
Contents
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.
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
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).