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
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
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
- 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.
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
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:
- The project is merged back into the mainline Eclipse Platform top-level
- The project is moved to a permanent state as a Tools Platform project.
- The technology proves to be insufficient for Eclipse and the work is set
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.
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.
- Mitch Sonies
- Thomas Hallgren
- Kenneth Olwing
- Pontus Rydin