Nexus Project
From Eclipsepedia
Contents |
Introduction
The Nexus Project is a proposed open source project under the Eclipse Technology Project. One aspect of Nexus can be thought of 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-projects can be hosted by interested parties and to lower the overhead associated with creating and managing a project so the resulting overhead is in line with the small size of these projects. To that end, the Nexus project will be responsible for infrastructure and process documentation around creating, housing, building and distributing micro-projects. Existing solutions such as the build system that grew out of the EMF project and is now being widely shared will be re-used where appropriate. New content, such as FAQs and project templates targeted at micro-projects specifically will be created. After the Nexus project gets off the ground, one important function of the project would be publicizing its existence.
Upon maturity, the exit strategy for Nexus out of the Technology project would be to become a separate top-level project.
Rules for Sub-Projects
- Sub-projects must follow the Eclipse Development Process.
- If a project does not show any committer activity for 6 months, it will be archived.
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-projects are potential committers on this project. The following people have volunteered to be the initial committers:
- Konstantin Komissarchik, Oracle (Project Lead)
- Scott Lewis
- Ed Merks
- Eugene Kuleshov
- Oisin Hurley
Interested Parties
Interest has been expressed by the following projects:
- WTP
- ECF
- EMF
- STP
Potential Initial Projects
The following projects 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)
- Data Model Wizard Framework (suggested by Kaloyan Raev) : Extends the wizards framework provided by the Eclipse Platform. Simplifies data collection, operation execution and wizard generation by storing the user input in a property-based data model. Most of the WTP wizards are based on this framework.
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>
<oisin.hurley> I certainly agree with the need for de-silo-ization of important independent elements within the larger projects. I attempted to make a start on something like this a couple of years ago, with the proposal to the Architecture Council to construct a searchable 'component catalog', so that people could check for capabilities before re-implementing them. You can see [some] [attempts] to kick-start it. While there was plenty of interest in principle, it seems most projects were far too busy to help out at that time. I would like to see this new effort work. </oisin.hurley>