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 "COSMOS Design 300044"
m (→References) |
m (→References) |
||
| Line 94: | Line 94: | ||
* [http://www.eclipse.org/equinox/server/http_in_equinox.php Embedding an HTTP server in Equinox] | * [http://www.eclipse.org/equinox/server/http_in_equinox.php Embedding an HTTP server in Equinox] | ||
* [http://docs.codehaus.org/display/JETTY/OSGi+Tips OSGi Tips] | * [http://docs.codehaus.org/display/JETTY/OSGi+Tips OSGi Tips] | ||
| − | + | * [http://wiki.eclipse.org/Equinox/p2/Concepts Equinox P2 Concepts] | |
[[Category:COSMOS_Bugzilla_Designs]] | [[Category:COSMOS_Bugzilla_Designs]] | ||
Latest revision as of 11:25, 25 January 2010
Contents
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 |
|
Workload Estimation
| 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
- Engine/Touchpoint Instructions
- Equinox p2 Installer
- Getting Started for Developers
- Installing software using the p2 director application
- P2 Install Example
- p2 updates for Eclipse RCP applications
- p2 Publisher
- Getting Started Admin UI
- Getting Started for Releng
- Embedding an HTTP server in Equinox
- OSGi Tips
- Equinox P2 Concepts