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.
