Nexus Project
From Eclipsepedia
Contents |
Introduction
The Nexus Project is a proposed open source project under the Eclipse Tools Project. Think of Nexus as "Orbit for in-house components".
Background
With growth of Eclipse and creation of so many different projects, a pressure has been building to enable those projects to collaborate more effectively on common requirements. Currently, the only available means for making common code available to more than one project is to get that code into a project that is a common dependency for the projects in question. In many cases, this common dependency is the Eclipse Platform Project. This pattern has repeated so many times that "push to platform" is part of the Eclipse lexicon. Needless to say, this approach does not scale or lead to a modular architecture. It is undesirable to have the core Eclipse Platform grow without bound by absorbing all of the code that other projects need to share. The platform team has been fairly good at fending off these attempts and many past attempts at pushing to platform have failed. Lacking any other reasonable option, the committers in question would typically give up the attempt to share code and build different solutions for the same problem within the walls of the respective projects. This has lead to a silo effect which hurts not only committer productivity and cross-project integration, but causes usability issues for end-users.
In addition to the above problem, it is too difficult for features that do not fall within scope of an existing project but are too small to be a project in their own right to exist at Eclipse. This problem affects not only committers on existing Eclipse projects, but also newcomers to Eclipse. The barrier to entry for an individual or small groups with ideas for new functionality is needlessly high.
Scope
The objective of the Nexus project is to provide a location where micro-components can be easily created by interested parties and made available for consumption by other Eclipse projects or directly by end-users. To that end, the Nexus project will be responsible for the infrastructure and processes around creating, housing, building and distributing micro-components.
Rules for Components
1. Component must specify its scope as part of component proposal. The scope must be reasonably constrained in nature and should not be as broad as a scope of a typical Eclipse project. Scope overlap with existing Eclipse projects or existing Nexus components is generally discouraged. If component scope does overlap with an existing project at Eclipse, the existing project must agree that Nexus is the correct place for the component.
2. Component must have at least one active committer. The initial set of committers on the component will be established at the time of component's creation. Any additional committers must be voted in by component's existing committers. If all of component's committers become inactive for a prolonged period of time, the component can be de-activated and archived at the discretion of the Nexus PMC. An archived component can be re-activated by petitioning Nexus PMC and by demonstrating willingness and resources to maintain the component. If Nexus PMC accepts component re-activation, the petitioners will designate a new set of committers. Any of component's committers from component's prior existence will no longer be committers, but can be voted in as appropriate by component's new committers.
3. Component must designate one of its committers to serve as the component lead.
4. Component team must act in a manner that is consistent with Eclipse Development Process and general open source principles.
Simultaneous Releases
The Nexus Project will attempt to join the yearly Eclipse Simultaneous Release train. Due to the expected diverse nature of components, the Nexus Project itself would not have a release train offset. Instead, those components that choose to join the release train will specify their offset. A Nexus component is not required to join the release train, but any that do are expected to follow the rules and requirements defined for participation in the simultaneous release.
Proposed initial committers and project lead
The initial committers will be drawn from the Eclipse developer community. Developers with experience in build infrastructure as well as those with an ongoing need for micro-components are potential committers on this project. The initial committers are:
- Konstantin Komissarchik, BEA (Project Lead)
- Scott Lewis, BEA
- Ed Merks, IBM
- Eugene Kuleshov
Interested Parties
Interest has been expressed by the following projects:
- WTP
- ECF
- EMF
Initial Components
The following components will serve as test subjects as Nexus project is getting off the ground.
- Faceted Project Framework : Facility for decomposing Eclipse projects into an extensible set of units of functionality (called facets) that can be easily added and removed by the user. This is a mature component that currently resides in WTP and would benefit the community better by having wider exposure. (initial committers: Konstantin Komissarchik)
- Eclipse Communication Framework : Several multi-protocol APIs/components, usable and useful in multiple execution environments (e.g. CDC 1.0, CDC 1.1, Eclipse, Equinox servers, etc).
- Async File Transfer -- Being used for Equinox Provisioning in Ganymede.
- Service Discovery
- Datashare/Asynch Messaging Channels
- Remote OSGi Services
- Presence/IM/Chat
- Basic image viewer/editor (Eugene Kuleshov)
Discussion
<nickb> Spoke with Konstantin about this proposal today, and he suggested that this wiki be a place to flush out questions and concerns. If you have comments to add here, please start a discussion below. </nickb>