Equinox p2 touchpoint

Installable units are marked with a type identifying the touchpoint responsible for their handling. For example, an IU delivering an OSGi bundle will be of type "OSGi". The touchpoint data contains information required to apply the software lifecycle (install, uninstall, update, configure, etc).

Touchpoint data

Even though an IU has a primary touchpoint type, it is frequent for the touchpoint data to have to carry on actions not directly relating to this primary type (e.g an OSGi IU may need to chmod a dll).

When we initially discussed the idea of touchpoint, we thought that the actions used in touchpoint data would be constrained by the primary type of the IU and that touchpoints would be responsible for defining and implementing all the actions they wanted to make available. However this approach suffered from the following drawbacks:

• multiple touchpoints would have to define the same actions (e.g the native and the osgi touchpoint would have had to define the chmod action) to use it
• contributing new actions could only be done through new touchpoints

The model we are now working under is the following:

• Anyone can register an action.
• Actions can be used in any touchpoint data, see next line for exceptions.
• Some actions can only be used in the IU of a certain type. These actions are said to be touchpoint sensitive. The applicable touchpoint is defined when the action is registered.
• Actions provide a do / undo capability and must implement IUndoableOperation and are provided a memento to store informations.

The concrete syntax / mechanism to register actions has not yet been defined, however something like what is provided in the org.eclipse.core.commands plugin is interesting since it offers a decoupling of the action and the actual implementation.

Syntax of the touchpoint data

We are currently using javascript, but it will be replaced by something else. We are thinking about using org.eclipse.core.expressions.

Dismissed alternatives

• Allow for hierarchy of touchpoints. For example the OSGi touchpoint could inherit from the native one. Problems: management of the hierarchy, need for multiple inheritance, visibility of inherited items, contribution of new actions not straightforward.
• One big pool of actions. Problem: not all actions are context free.