Difference between revisions of "Equinox/p2/Engine/Galileo"

Revision as of 11:03, 7 October 2008

Galileo Changes for the p2 Engine

The key building blocks for an Engine operation are the Phases, Touchpoints, and Actions used while performing the set of changes. Currently the touchpoint and action contribution model in p2 is limiting usage and will be one of the main areas where we will enhance p2.

Here are some problem areas we want to address:

Extensibility:

1. An IU may only reference and use actions from the single touchpoint that it is associated with.
2. There is no way to contribute "new" actions to an existing touchpoint.
3. As a result of (2) you have to write a new touchpoint if you want to do anything custom and in addition will likely end up copying many of the existing actions.
4. No support for general install handler like approaches. e.g. unzip and run this hunk of code as part of the install/uninstall

Usability:

1. Lack of validation mechanisms that provide the user the oppportunity to apply corrective action. For example, there is no way to indicate the need for user interaction when required configuration properties are missing.
2. General shortage of useful metadata to allow one to construct a useful IU authoring environment without having to know the inner details of phases, touchpoints, and actions.

Proposed changes:

Note: current activity is in the "engine_changes_3_5" branch for:
* org.eclipse.equinox.p2.engine
* org.eclipse.equinox.p2.tests
* org.eclipse.equinox.p2.touchpoint.eclipse
* org.eclipse.equinox.p2.touchpoint.native

Phases:

• Add a phase extension point (IU authoring metadata)

-id
-version
-class
-key (instructions key)
-description (localizable) (parameters)

• Add new validation phases similar to sizing for unconfigure, uninstall, property, install, configure. This will allow us to create a validation phase set the ui or other clients can run to determine if there are elements used by the engine that need to be first installed or configured.

Touchpoints:

• Augment the existing touchpoint extension (IU authoring and validation metadata)

-id
-version
-class
-description (localizable) (parameters)
 -profileProperties
  -name
  -description (localizable)
  -type (string, number, boolean)
  -use (optional, required)
  -default (implies optional)

• The "data" element in the touchpoint extension-point schema was defined but never used and will be removed from the schema. This is no change in functionality and is formalizing what we have in the code where it is ignored.
• Any adjustments required as a result of changing the action lookup. In particular touchpoints will only be involved in phases where there are associated actions. There will be changes to allow a touchpoint to hold or at least access state for the duration of an engine operation.
• better validation support to verify necessary profile properties are set before proceeding.

Provisioning Actions:

• Add an "actions" extension point (touchpint reference and IU authoring metadata)

-id
-version
-class
-touchpointId
-touchpointVersion
-description (localizable) (parameters)

• Adjust the Engine's action lookup to use actions extensions
• Touchpoint Data instructions will likely have to be updated to include information to disambiguate actions.

<instruction key='configure' 
 actions='org.eclipse.equinox.p2.touchpoint.eclipse.setStartLevel;version=[1.0,2.0),
  org.eclipse.equinox.p2.touchpoint.eclipse.markStarted;version=[1.0,2.0)'>
 setStartLevel(startLevel:2);markStarted(started: true);
</instruction>

• For backwards compatibility actions would by default looked up in the IU's touchpoint
• Provide a "new" action that will allow for simple unzip and run use-cases.
• Removal of re-dundant actions where possible