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 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

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