View source for Provisioning Project Intersections

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 [http://www.eclipse.org/ecf/ 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 [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]] 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
: [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.
; Installation Manager
: [http://wiki.eclipse.org/index.php/GPW_Lightning_Retrospectives#IBM_Installation_Manager Installation Manager] is a proprietary technology used for provisioning of Eclipse-based IBM products.
; Linux Distros
: A focus of the [http://www.eclipse.org/linuxtools/ 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 [http://fedoraproject.org/wiki/Tools/yum yum] on [http://fedoraproject.org/wiki/ Fedora]).
; Maya
: [[Maya]] is a sub-project of the [[Eclipse Technology]] project that focuses on provisioning and installation technology
; Smartup
: [http://wiki.eclipse.org/index.php/GPW_Lightning_Retrospectives#Smartup_software_update 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 ==

[[Image: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

[[Category:Provisioning|Project Intersections]]