Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Provisioning Project Intersections"

(Definition of Parties)
 
(3 intermediate revisions by 2 users not shown)
Line 14: Line 14:
 
: EPP stands for the [http://www.eclipse.org/epp/ Eclipse Package Project]. EPP is an [[Eclipse Technology]] sub-project that is focused on creating entry level Eclipse downloads, and providing technology for creating such packages.
 
: EPP stands for the [http://www.eclipse.org/epp/ Eclipse Package Project]. EPP is an [[Eclipse Technology]] sub-project that is focused on creating entry level Eclipse downloads, and providing technology for creating such packages.
 
; Equinox
 
; Equinox
: [[Equinox]] is a sub-project of the Eclipse project. In this context, we are referring to the [[Equinox Provisioning]] work area in the Eclipse incubator.
+
: [[Equinox]] is a sub-project of the Eclipse project. In this context, we are referring to the [[Equinox p2]] work area in the Eclipse incubator.
 
; Expeditor
 
; Expeditor
 
: [http://wiki.eclipse.org/index.php/GPW_Lightning_Retrospectives#IBM_Lotus_Expeditor Lotus Expeditor] is an Eclipse-based product that has its own provisioning mechanism based on the existing Update Manager.
 
: [http://wiki.eclipse.org/index.php/GPW_Lightning_Retrospectives#IBM_Lotus_Expeditor Lotus Expeditor] is an Eclipse-based product that has its own provisioning mechanism based on the existing Update Manager.
Line 37: Line 37:
 
(''italics'' means interested party, but not necessarily an active participant)
 
(''italics'' means interested party, but not necessarily an active participant)
  
Metadata
+
'''Metadata'''
 
* Everyone
 
* Everyone
  
Admin/Advanced UI
+
* Buckminster
 +
 
 +
Buckminster has four types of meta-data. Two that controls behavior (one for the resolver and one for the installer), one that describes a component (the component specification) and one that describes the result of a resolution (the bill of materials).
 +
 
 +
'''Component Specification (CSPEC)'''
 +
Names the component and its version. Lists the component dependencies, its attributes and how attributes implies dependencies.
 +
Attributes can be derived, i.e. created by calling on actors. Dependencies are described using version designators
 +
(similar to OSGi version ranges but not limited to OSGi version syntax).
 +
 
 +
'''Component Query (CQUERY)'''
 +
Describes how a component specification should be resolved into a bill of materials.
 +
 
 +
'''Bill of Materials (BOM)'''
 +
The graph that describes a resolution of a cspec. The graph contains explicit pointers to locations from where actual
 +
components can be obtained. The pointers typically include fixed version information (i.e. not ranges).
 +
 
 +
'''Materialization Specification (MSPEC)'''
 +
Describes how to materialize components from a Bill of Materials. Where to store, what to do if the designated location is not empty,
 +
resolution of ambiguities in project naming (features named same as plugins for instance) etc. The MSPEC is in the works and not yet
 +
part of the release.
 +
 
 +
''Related thoughts''
 +
 
 +
When we resolve, we start with a top-level CSPEC. Package import/export must be resolved within that scope. At present, we can define package exports as attributes but we have no generic way of describing a package requirement without going through a component. In order to do that we would need to introduce an unqualified attribute dependency, i.e. a component could state "I need this attribute, I don't care who provides it". Key thing is the resolution scope.
 +
 
 +
 
 +
'''Admin/Advanced UI'''
 
* Maya
 
* Maya
 
* Equinox
 
* Equinox
  
Central Manager
+
'''Central Manager'''
 
* Maya
 
* Maya
 
* ''Installation manager''
 
* ''Installation manager''
Line 50: Line 76:
 
* ''Smartup''
 
* ''Smartup''
  
Tools
+
'''Tools'''
 
* Maya
 
* Maya
 
* Equinox
 
* Equinox
Line 57: Line 83:
 
* ''Installation Manager''
 
* ''Installation Manager''
  
Director
+
* Buckminster
 +
 
 +
Buckminster comes in two flavors. One intended for the IDE and one that is for headless execution and intended for scripting
 +
scenarios such as nightly builds etc. It's designed for ease of use both from the command-line and from ant-scripts.
 +
We also have a Java Web Start enabled minimal installer.
 +
 
 +
'''Director'''
 
* Maya
 
* Maya
 
* Equinox
 
* Equinox
 
* Smartup
 
* Smartup
 +
 
* Buckminster
 
* Buckminster
  
Engine
+
Buckminster allows for registration of resolvers. At present, we have three types:
 +
 
 +
'''The main resolver'''
 +
A dispatcher that calls registered resolvers in a specified order.
 +
 
 +
'''Resource Map resolver'''
 +
A resolver that is backed by a resource map (an XML document) where component names are mapped to search paths using regular expressions.
 +
A search path consist of a sequence of providers. A provider knows how to read a certain type of remote source and how to interpret
 +
what it finds there by use of reader and component types.
 +
 
 +
'''Remote resolver'''
 +
Uses web-services to call on a remote resolver.
 +
 
 +
'''Engine'''
 
* Equinox
 
* Equinox
 
* Maya
 
* Maya
 
* Smartup
 
* Smartup
 +
 
* Buckminster
 
* Buckminster
  
End-user UI
+
The Buckminster engine consists of two major parts. The resolver, responsible for the resolution of a CSPEC into a BOM.
 +
(perhaps this is the "Director"?), and the materializer that downloads and installs components based on a BOM. The engine tries
 +
to make use of existing technology to the extent possible. We rely heavily on the Eclipse Update Manager, the CVS plugin,
 +
the svnclient (from tigris.org), and have a current effort to bring in the Maven embedder technology.
 +
 
 +
'''End-user UI'''
 
* Equinox
 
* Equinox
 
* Maya
 
* Maya
 
* ''Installation Manager''
 
* ''Installation Manager''
  
Touch Points
+
'''Touch Points'''
 
* Equinox
 
* Equinox
 
* Maya
 
* Maya
  
Native Installer/Bootstrap
+
'''Native Installer/Bootstrap'''
 
* EPP
 
* EPP
 
* Maya
 
* Maya
  
Repository
 
 
* Buckminster
 
* Buckminster
 +
 +
The smallest functional Buckminster configuration is about 2MB and can be spawned using Java Web Start. The JWS URL contains
 +
a link appointing a CQUERY or BOM. JWS makes sure Buckminster is installed and correctly configured. It then uses it to resolve and materialize.
 +
 +
'''Repository'''
 
* Equinox
 
* Equinox
 
* Maya
 
* Maya
Line 89: Line 145:
 
* Spaces
 
* Spaces
  
Transport
+
* Buckminster
 +
 
 +
Rather then defining a repository, Buckminster is designed to be extended to read any type of repository and to make sense of what
 +
it may find there. We try to generalize the concept of the component, it's dependencies, and attributes in our CSPEC.
 +
All repositories are interpreted as a container of components described using CSPEC's.
 +
 
 +
'''Transport'''
 
* Equinox
 
* Equinox
 
* Smartup
 
* Smartup
Line 95: Line 157:
 
* ''Maya''
 
* ''Maya''
  
Delta Server/mechanism
+
'''Delta Server/mechanism'''
 
* Smartup
 
* Smartup
  
Profile Management
+
'''Profile Management'''
 
* Equinox
 
* Equinox
 
* Maya
 
* Maya
* Buckminster
 
 
* EPP
 
* EPP
 +
 +
* Buckminster
 +
 +
The closest we come to this is probably our Component Query/Materialization Spec.
  
 
Integration with other mechanisms
 
Integration with other mechanisms
Line 112: Line 177:
 
* Multiple directors
 
* Multiple directors
  
[[Category:Provisioning]]
+
[[Category:Provisioning|Project Intersections]]

Latest revision as of 14:18, 1 October 2007

There are many projects in the Eclipse community that are involved in aspects of software provisioning. This page is intended to track notable areas of Eclipse provisioning where the various efforts intersect. Tracking these intersection points over time, along with the parties of interest, allows us to see who may be interested when problems (or difficulties) arise in these areas. This page can also be used to set up ad-hoc working groups, or dynamic teams to focus work efforts in these areas.

This page is written by and for the entire Eclipse community. If you are working on something that relates to one of these areas, please put down the name of your project, or just your name in the case of an individual contributor. If new intersection points come up, add it to the list. If older intersection points become irrelevant or prove to be uninteresting, they can be removed from the list.

This page is based on an initial list of project intersections developed at the Ganymede Provisioning Workshop. See the Ganymede Provisioning Workshop Breakout Results page for the original list.

Definition of Parties

Here are the interested parties, along with pointers for more information:

Buckminster
Buckminster is an Eclipse Technology sub-project. In the area of provisioning, they have particular expertise in provisioning of Eclipse workspaces.
ECF
ECF stands for the Eclipse Communications Framework. ECF is an Eclipse Technology sub-project that is focused on supporting all manner of communications infrastructure from basic transports to presence, instant messaging, voice, ...
EPP
EPP stands for the Eclipse Package Project. EPP is an Eclipse Technology sub-project that is focused on creating entry level Eclipse downloads, and providing technology for creating such packages.
Equinox
Equinox is a sub-project of the Eclipse project. In this context, we are referring to the Equinox p2 work area in the Eclipse incubator.
Expeditor
Lotus Expeditor is an Eclipse-based product that has its own provisioning mechanism based on the existing Update Manager.
Installation Manager
Installation Manager is a proprietary technology used for provisioning of Eclipse-based IBM products.
Linux Distros
A focus of the Linux Distros project is on packaging and distributing Eclipse technology in Linux distributions. In the context of provisioning, they want to ensure Eclipse provisioning works well in a Linux environment, and interacts well with native provisioning technology provided by the various distros (such as yum on Fedora).
Maya
Maya is a sub-project of the Eclipse Technology project that focuses on provisioning and installation technology
Smartup
Smartup is a commercial provisioning technology that is not currently based on Eclipse.
Spaces
The Spaces project involves hosting services for Eclipse plugin development. Their interest in provisioning is related to ensuring that Eclipse provisioning infrastructure can interact with the Spaces discovery service.

Component Diagram

Prov intersect diagram1.png

The above picture (work in progress) shows the rough components and their relationships as described below. This is a bit simplified from the version derived at the workshop as some of the lines did not accurately represent what may become the real relationships.

Project Intersections

(italics means interested party, but not necessarily an active participant)

Metadata

  • Everyone
  • Buckminster

Buckminster has four types of meta-data. Two that controls behavior (one for the resolver and one for the installer), one that describes a component (the component specification) and one that describes the result of a resolution (the bill of materials).

Component Specification (CSPEC)
Names the component and its version. Lists the component dependencies, its attributes and how attributes implies dependencies.
Attributes can be derived, i.e. created by calling on actors. Dependencies are described using version designators
(similar to OSGi version ranges but not limited to OSGi version syntax).
Component Query (CQUERY)
Describes how a component specification should be resolved into a bill of materials.
Bill of Materials (BOM)
The graph that describes a resolution of a cspec. The graph contains explicit pointers to locations from where actual
components can be obtained. The pointers typically include fixed version information (i.e. not ranges).
Materialization Specification (MSPEC)
Describes how to materialize components from a Bill of Materials. Where to store, what to do if the designated location is not empty,
resolution of ambiguities in project naming (features named same as plugins for instance) etc. The MSPEC is in the works and not yet
part of the release.

Related thoughts

When we resolve, we start with a top-level CSPEC. Package import/export must be resolved within that scope. At present, we can define package exports as attributes but we have no generic way of describing a package requirement without going through a component. In order to do that we would need to introduce an unqualified attribute dependency, i.e. a component could state "I need this attribute, I don't care who provides it". Key thing is the resolution scope.


Admin/Advanced UI

  • Maya
  • Equinox

Central Manager

  • Maya
  • Installation manager
  • Expeditor
  • Smartup

Tools

  • Maya
  • Equinox
  • EPP
  • Expeditor
  • Installation Manager
  • Buckminster
Buckminster comes in two flavors. One intended for the IDE and one that is for headless execution and intended for scripting
scenarios such as nightly builds etc. It's designed for ease of use both from the command-line and from ant-scripts.
We also have a Java Web Start enabled minimal installer.

Director

  • Maya
  • Equinox
  • Smartup
  • Buckminster

Buckminster allows for registration of resolvers. At present, we have three types:

The main resolver
A dispatcher that calls registered resolvers in a specified order.
Resource Map resolver
A resolver that is backed by a resource map (an XML document) where component names are mapped to search paths using regular expressions.
A search path consist of a sequence of providers. A provider knows how to read a certain type of remote source and how to interpret
what it finds there by use of reader and component types.
Remote resolver
Uses web-services to call on a remote resolver. 

Engine

  • Equinox
  • Maya
  • Smartup
  • Buckminster
The Buckminster engine consists of two major parts. The resolver, responsible for the resolution of a CSPEC into a BOM.
(perhaps this is the "Director"?), and the materializer that downloads and installs components based on a BOM. The engine tries
to make use of existing technology to the extent possible. We rely heavily on the Eclipse Update Manager, the CVS plugin,
the svnclient (from tigris.org), and have a current effort to bring in the Maven embedder technology.

End-user UI

  • Equinox
  • Maya
  • Installation Manager

Touch Points

  • Equinox
  • Maya

Native Installer/Bootstrap

  • EPP
  • Maya
  • Buckminster
The smallest functional Buckminster configuration is about 2MB and can be spawned using Java Web Start. The JWS URL contains
a link appointing a CQUERY or BOM. JWS makes sure Buckminster is installed and correctly configured. It then uses it to resolve and materialize.

Repository

  • Equinox
  • Maya
  • Smartup
  • Spaces
  • Buckminster
Rather then defining a repository, Buckminster is designed to be extended to read any type of repository and to make sense of what
it may find there. We try to generalize the concept of the component, it's dependencies, and attributes in our CSPEC.
All repositories are interpreted as a container of components described using CSPEC's.

Transport

  • Equinox
  • Smartup
  • ECF
  • Maya

Delta Server/mechanism

  • Smartup

Profile Management

  • Equinox
  • Maya
  • EPP
  • Buckminster
The closest we come to this is probably our Component Query/Materialization Spec. 

Integration with other mechanisms

  • Equinox
  • Linux Distros

Cross cutting concerns

  • Integration with other mechanisms
  • Multiple directors

Copyright © Eclipse Foundation, Inc. All Rights Reserved.