The Eclipse Orbit Project
The Eclipse Orbit Project is a proposed open source project under the Eclipse Tools 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.tools.orbit newsgroup.
The Eclipse community is increasingly embracing and using code from other open source projects. Traditionally each Eclipse project has submitted requests to use the libraries they need and, upon approval, the libraries have been integrated into the project's plug-ins and shipped. This situation presents a number of challenges.
Bundlings: There are often several ways of "bundling" a third party library. A JAR can be wrapped in a bundle or have bundle metadata injected into it. Bundle names and versions must be selected. Packages must be exported with the appropriate visibilities, directives and versions. Libraries that consist of multiple JARs may be packaged as one bundle or with a bundle for each JAR. In fact, libraries might be simply included directly in an existing bundle of the consuming project. Since each team performs this packaging independently, the chances are high that the approaches taken will diverge. This leads to confusion and challenges when composed systems contain incompatible bundlings of the same libaries.
Componentization: Often times a "library" is actually a composition of other libaries with some additional function. These internal libraries are often interesting in and of themselves. For example, in Eclipse 3.2 the Tomcat plug-in also includes various Apache Commons libraries (logging, collections, modeler, etc.), mx4j, Jakarta regexp, servlet API and Jasper. All of these JARs are interesting and useful, independent of Tomcat. Under the current approach, when a team requests the use of Tomcat, the function as a whole is analyzed and approved rather then looking at the individual components. In some cases components are not even needed for the required use of the requested function. For example, mx4j is not really needed for the Eclipse Help use of Tomcat. Further, since these common libraries appear in many configurations, they are repeatedly reviewed and analyzed as teams request approval for these different configurations.
Sharing: Even with a common vision as to how libraries should be converted to bundles, each team must duplicate the packaging effort and maintenance. Further, since the current approach is compartmentalized, it often happens that project teams are unaware of the libraries used by each other. This results in gratuitous duplication of content in the Eclipse downloads (e.g. Callisto contains several copies of Xerces and commons logging, etc.) and version misalignments. The lack of transparency also clogs the IP clearance process since teams do not know that others are already using the library they need or one which provides equivalent function.
Community: The Eclipse committer community is not unique in this need for bundled versions of existing libraries. Many systems built by others include the very same code. Again, these libraries are bundled by different people (duplicating effort and encouraging divergence) and managed and delivered separately (resulting in incompatibilities) and raising the bar for Eclipse adoption.
This project is intended to be
- a source of approved and bundled content for qualifying Eclipse projects and the community as a whole
This project is not intended to
- support code development
- replace the IP process
- do all the packaging work for teams
This project will provide a repository of bundled versions of third party libraries that are approved for use in one or more Eclipse projects. The repository will maintain old versions of such libraries to facilitate rebuilding historical output. It will also clearly indicate the status of the library (i.e. the approved scope of use). The repository will be structured such that the contained bundles are easily obtained and added to a developer's workspace or target platform.
One of the key issues with the current situation is the inconsistency in naming, versioning and form of bundled third party libraries. This project will, as a mainline activity, provide a repository of approved and bundled third party libraries to authorized project teams. This eliminates duplicated work and bundle naming, structuring and versioning variations.
Crucially, no development is carried out in this project. Teams proposing the use of a third party library for the first time are able to work with the community developed here and other potential users of the library to derive an appropriate selection and packaging of the function they need. For example, a team may start out with "a need for Jetty." As we have seen, systems like Jetty often include several JARs and a wide variety of infrastructure pieces (e.g. Apache Commons Logging). In some cases this additional function is not needed, is already approved and available, or has special packaging needs. Through this project the teams needing function can arrive at a mutually agreeable form of the required function.
It is important to note that this project will not be responsible for doing the packaging work. That responsibility remains with the teams seeking to use the requested library. This project is to act as a hub or focal point for people with needs related to third party libraries and those with related technical expertise.
The bundled libraries are retained and made available within the project in various ways (e.g. download zip, update site, etc.) for use in the projects that have received the appropriate approvals. Note that teams seeking to use a library must still follow the IP process. For example, the current process calls for all third party code use to be cleared by the Foundation. So even if a library is approved by the Foundation for use by all projects, project teams must notify the Foundation of their intentions to use a library. This allows their use to be tracked and facilitates version synchronization (e.g. stepping up to new releases) as well as notification of issues found with approved and previously distributed libraries.
Existing standards and projects leveraged
This project will mainly use the existing developer infrastructure (e.g. CVS, Bugzilla, etc.) to manage library contribution requests and the libraries themselves.
This project will be organized into one top-level component:
- Bundles: bundlings of approved third party libraries in orbit around Eclipse.
Proposed initial committers and project lead
The initial committers will be drawn from the Eclipse developer community. Developers with experience with, interest in, and/or an ongoing need for shared code and bundling are potential committers on this project. The initial committers are:
- Jeff McAffer (Project Lead)
- Pascal Rapicault
- David Williams
- Simon Kaegi
- Bjorn Freeman-Benson
- John Graham
Potential commiters are kindly invited to express their interest on the eclipse.tools.orbit newsgroup or via email.
As projects propose the use of additional third party libraries and their use is approved, one of their team will add the bundled libraries to the Orbit project. If they do not already have a committer on Orbit, they will be able to petition for a committer to be added on the basis that they are making an initial code contribution to the project. They will also commit to ongoing maintenance of that contribution as well as interacting with other Eclipse projects which have an interest in the same code base.
Interest has been expressed by the following projects:
To express support, concern, or constructive opinions regarding the formation of this proposed Tools project, you are encouraged to utilize the eclipse.tools.orbit newsgroup.
The team will initially look at the set of libraries currently approved for use in Eclipse (e.g. those included in Callisto) and attempt to rationalize their form. Below is an example list of the bundles to be added/maintained in Orbit:
- Various Apache Commons projects including Logging, HTTP Client, Codec
- Apache XMLRPC
- Servlet API 2.3 and 2.4
This project has no particular deliverables so a standard milestone-based roadmap does not make sense here. Having said that, we expect to have an initial set of library entries in the database and bundles in the repository within the first three months of this project being provisioned. As the goal of Orbit is to support the other Eclipse projects through common shared bundles, the Orbit Roadmap will be coordinated with significant releases of the major Eclipse projects.