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.
Difference between revisions of "Equinox/p2/GeneratingCUs"
(→Configuring Products) |
m (just added category p2) |
||
| Line 64: | Line 64: | ||
===Other Considerations=== | ===Other Considerations=== | ||
If we expect people to simply include the configured features in the products/features then this requires actual configured.feature jars for build purposes. If the configured features are simply IUs in the metadata without an actual jar artifact, then people need to be able to specify includes/requires on IUs directly. | If we expect people to simply include the configured features in the products/features then this requires actual configured.feature jars for build purposes. If the configured features are simply IUs in the metadata without an actual jar artifact, then people need to be able to specify includes/requires on IUs directly. | ||
| + | |||
| + | [[Category:Equinox p2|Generating CUs]] | ||
Revision as of 06:07, 11 February 2009
Contents
Generating Configuration Metadata
There are bundles that require special configuration in order to work properly. Such configuration depends on the product they are included in, however most of the time, such configuration information is reusable across different products. Most commonly this configuration information is start levels, however it can include actions for which there is no current mechanism to generate configuration metadata.
- People composing products don't necessarily know the details how all the bundles need to be configured
- People composing product would like to reuse pre-existing configuration information
The proposed solution is allow a feature to include a p2.inf specifying information on how configure bundles. CUs will then be generated and included in the feature.
Configuring RCP
org.eclipse.rcp includes a few bundles that need configuring, the normal configuration is as follows:
- org.eclipse.core.runtime needs to be started
- org.eclipse.equinox.common needs start level 2
- org.eclipse.equinox.simpleconfigurator needs start level 1
- org.eclpse.update.configurator should have a property "org.eclipse.update.reconcile=false"
To do this, create a new feature org.eclipse.rcp.configure
- build.properties : bin.includes is empty, there is no rcp.configure.jar (see Other Considerations below)
- includes org.eclipse.rcp (optional)
- contains a p2.inf with required properties
When generating metadata for org.eclipse.rcp.configure, the result is
org.eclipse.rcp.configure.feature.group
- includes org.eclipse.rcp.feature.group
- includes generated CUs
People authoring an rcp product can include org.eclipse.rcp.configured in their product to get rcp plus the required CUs
Configuring Features
In general there are decisions around how to structure configuration features
- Is this feature intended for general consumption by others?
- What other features are required/included by this feature.
Consider org.eclipse.platform, it includes org.eclipse.rcp and org.eclipse.p2.user.ui. Both rcp and p2.user.ui require configuration, but nothing directly in platform does. However, since org.eclipse.platform is commonly reused by others, it would be useful to have
org.eclipse.platform.configured -includes org.eclipse.rcp.configured -includes org.eclipse.equinox.p2.user.ui.configured
org.eclipse.platform.configured is generally reusable, people don't need to know that if they include platform they need to include configuration for rcp and p2.user.ui. They can just include platform.configured.
We can also decide to require other .configured features instead of including them. Consider features that don't form products on their own but are commonly bundled into other products. If such a feature required configuration of its own, it could require configuration of platform instead of including it.
Configuring Products
Products should be organized so that the product IU includes a product.config IU. The product.config IU then includes all necessary feature.configured IUs (who in turn include all the CUs). The product.config IU is then reusable by other products.
- org.eclipse.platform.ide is a product, contains org.eclipse.platform.ide.configured
- org.eclipse.sdk.ide is a product, include org.eclipse.platform.ide.configured
- com.acme.awesomeness is a product, include org.eclipse.sdk.ide.configured
- org.eclipse.sdk.ide is a product, include org.eclipse.platform.ide.configured
p2.inf format
See also Authoring Touchpoint Data The format for specifying configuration information for other bundles could be similar to source generation in pde.build. We need to be able to do the following:
- specify bundle id (& version?)
- specify the name for the new CU
- specify touchpoint instructions
- perhaps specify a config filter that the new CU will receive
Consider perhaps the following:
configure.prefix = <cuPrefix> configure.<phase>@<bundle.id>=<actions>
With the result being a CU named "<cuPrefix>.<bundle.id>" with host <bundle.id> and the given touchpoint actions.
Other Considerations
If we expect people to simply include the configured features in the products/features then this requires actual configured.feature jars for build purposes. If the configured features are simply IUs in the metadata without an actual jar artifact, then people need to be able to specify includes/requires on IUs directly.