Skip to main content

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.

Jump to: navigation, search

COSMOS Design 300044

Design/document SDD runtime interaction/integration with P2

This is the design document for bugzilla 300044.

Change History

Name: Date: Revised Sections:
Jeff Hamm January 19, 2010
  • Initial version

Workload Estimation

Rough workload estimate in person weeks
Process Sizing Names of people doing the work
Design 1 Jeff Hamm
Code 0
Test 0
Documentation 0
Build and infrastructure 0
Code review, etc.* 0
TOTAL 1

'* - includes other committer work (e.g. check-in, contribution tracking)

Purpose

This work documents a deep dive into the P2 constructs of equinox and discusses various levels of integration and usage patterns to explore. The outcome of these discussions is to align resources in COSMOS with the efforts in P2 in order to provide synergy between the projects where possible

Overview

In examining P2, there are several features that offer up the promise of providing benefit and ultimately alignment with the work being done in COSMOS.

Black Box

Repositories

One of the first areas that COSMOS can take advantage of P2 is in the use of the the artifact and metadata repositories. These respositories, although simplier in nature than a COSMOS MDR, provides the capabilities to house not only the COSMOS Runtime, but also can be used to house the packages that would be installed.

Through the combination of features and plugins, eclipse gives the abilitity to wrapper both plugins and data into features and these features can be be grouped together. By leveraging the eclipse framework components of the PDE and through the P2 Publisher, a bundle consisting of the runtime can be housed within a P2 repository. Likewise, using the same tooling, artifacts that represent the data of an installable product can be configured to produce the same type of bundle into a P2 repository as well.

This combination of features and plugins has been roughly prototyped using the tooling from P2 and eclipse and an update site with artifact and content xml data created.

Co-Locating P2 and SDD Runtime

The idea of using the out-of-the-box P2 stems from the direct use of the repositories. In this use case, P2 is used as a delivery and unpackaging mechanism where it is leveraged to fetch the required features and bundles from a known repository and extract them into the proper destination. Once P2 has delivered and "installed" the bundles, The SDD Runtime would then execute on the installed data and perform the necessary requirement checks as defined by the SDD and ultimately use the SDD Operations Handler(s) to manipulate the bits and perform any post configuration steps from a CL2 type implementation.

In this scenario, P2 and SDD Runtime would co-exist and perform separate functions as described above. A "wrapper" that would include both sets of tooling would be needed in order to faciliate the operations between the two. An example implementation could include the use of Jetty. The interface between the two would exist as a Servlet class that could understand the interactions of P2 and pass information on to the SDD Runtime. The HTTP interfaces of Jetty could then be leveraged as a Advisor interface allowing for interaction with the SDD Runtime during the install process through a RCP based application or though eclipse itself depending on the desired UI facade.

Integration

Integration of the SDD Runtime into the P2 architecture is at many levels. One of the largest challenge of integrating the SDD Runtime and P2 is in providing the drop-in for the Planner component of P2 so that it becomes SDD aware and is able to resolve requirement dependencies. Once this happens, this forces other integration components to be aligned with P2. Such an example would be the profile handlers would need to convert to touchpoint actions. Other design considerations made in COSMOS would have to be explored and implemented as well.

The interface to the planner is through the SimpleDirector(IDirector) implemention. This class marries the P2 Engine with the Planner.

The SimplePlanner(IPlanner) class of the org.eclipse.equinox.p2.director project provides the interface to the Provisioning portion of P2. Through this class, all the processing checks are made in order to properly determine the components that can be installed and what the dependencies are. Though the use of the Planner, P2 is able to construct a ProvisioningPlan, which includes Installable Units, Operands, Phase Sets, Phases, and Provisioning Actions.

Any migration to the P2 architecture would involve the translations of the SDD components to their correlating function within P2. An initial assessment of mapping shows many similaries such as InstallableUnits which exists in both architecture. Differences such as a P2 concepts of a profile vs. a COSMOS profile will need some considerations.

References

Retrieved from "https://wiki.eclipse.org/index.php?title=COSMOS_Design_300044&oldid=187043"

This page was last modified 11:25, 25 January 2010 by Eclipsepedia anonymous user Unnamed Poltroon.

Back to the top