Buckminster, Component Assembly Project

Introduction

The Buckminster, Component Assembly Project is a proposed open source project under the Eclipse Technology Project.

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process document) and is written to declare its intent and scope. This proposal is written to solicit additional participation and input from the Eclipse community. You are invited to comment on and/or join the project. Please send all feedback to the eclipse.technology.buckminster newsgroup.

Overview

Developers are increasingly working with complex component structures comprising code artifacts from a variety of sources implemented in disparate technologies. The Eclipse Plug-In Development Environment (PDE) currently provides an outstanding framework for developing componentized plug-ins and feature-sets. However, Eclipse provides only limited support for materializing a workspace—i.e. so that all component dependencies are fulfilled—a problem which is particularly acute in team-based development. Moreover, the PDE’s component management support is available only to components implemented as Eclipse plug-ins, which limits its applicability to other types of development projects.

The objective of the Buckminster, Component Assembly Project will be to leverage and extend the Eclipse platform to bring mixed-component development comparable to Eclipse plug-in development in terms of efficiency and ease of use, as well as to extend the Eclipse component dependency model to allow component materialization based on match rules. Buckminster will accomplish this objective by introducing a project-agnostic way of describing the component structure and dependencies of an arbitrarily complex development project, plus a mechanism for materializing all corresponding source and binary artifacts.

Buckminster will be implemented as a set of Eclipse plug-ins that complement existing Eclipse infrastructure. Functionality within the project’s initial functional scope will include the following:

• Complex dependency resolution, providing recursive resolution of dependencies leveraging existing Eclipse "Team Providers," with the addition of new retrievers, for exemplary purposes, covering source and binary artifacts that are not version-controlled in a traditional sense. Resolution will use a variety of versioning schemes and will be based on match rules similar to those found in the Eclipse plug-in framework. This will allow comparison of current and prior dependency resolutions to support update impact analyses.
• Uniform component dependency format, using a component-type agnostic mechanism for describing components and their respective targets and dependency requirements. Most Eclipse projects, and many other component types, have some level of dependency information that can be leveraged. Extensions can be added to provide additional strategies for dependency pattern recognition.
• Intelligent retrieval mechanisms, leveraging the Eclipse "Team Project Set" mechanism by separating the bill of material needed for a given configuration from its actual materialization. This is important since dependencies may appoint software that is locally installed on one machine but lacking on another. The bill of materials is typically shared between team members, although the materialization information may vary.
• Flexible project workspace binding, allowing components materialized on disc to be bound to a workspace in different ways, including "Proxy Projects" consisting of links to physical artifacts and auto-generated Eclipse project information. These capabilities are helpful when sharing code or other artifacts that are not eclipse projects.

The Buckminster Project’s initial scope will focus primarily on materialization of components based on dependencies and rules, although this scope may be expanded over time, to the extent appropriate and consistent with its objectives. One of a number of requirements that may be addressed in the future is tighter integration with Eclipse build systems. For example, this would allow fulfillment of pre-built artifacts by actually building source artifacts and then caching the results for group access.

Project Organization

We propose that this project be undertaken as a Technology subproject rather than part of the Eclipse Platform Project. Being a Technology subproject gives the project room to experiment with the technology without disruption to the mainline Eclipse developers and users.

The Buckminster Project will assist in the working with complex, multi-sourced component structures, which is of increasing interest to open source consortia, commercial vendors and internal users and developers of open source packages and distributions. Accordingly, it will be vitally important to include in this project individuals who are active participants in or consumers of other open source projects and can therefore represent a range of experiences and requirements.

It will also be important to retain as much continuity as possible with the existing Eclipse Platform; therefore, we will reach out to existing Platform committers for advice and for inclusion in this project.

Finally, since Technology Sub-projects are not meant to be ongoing, we foresee three possible evolutionary paths for the subproject:

1. The project is merged back into the mainline Eclipse Platform top-level project.
2. The project is moved to a permanent state as a Tools Platform project.
3. The technology proves to be insufficient for Eclipse and the work is set aside.

These paths are not mutually exclusive. Some combination of some or all of these paths may be the result of the work done in this project.

Interested Parties

This section captures the list of companies that have expressed interest in the project and/or its components, and as such will be updated periodically to reflect the growing interest in this project.

The Buckminster Project is being proposed by ObjectWeb in association with its individual members listed below. We anticipate adding members to the Buckminster Project team in conjunction with approval and launch of the project.

• Individuals from a variety of commercial software vendors and end-user organizations, including organizations that are members of ObjectWeb, have expressed an interest in participating in the project.
• Additional participants from the Eclipse community at large are also invited to participate.

Sponsoring Organization

• ObjectWeb

Initial Committers

• Mitch Sonies
• Thomas Hallgren
• Kenneth Olwing
• Pontus Rydin