Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[] Architecture Council Meeting in Chicago

Architecture Council Members,
As you know, the Q2 council meetings are being held in Chicago at the Hotel Allegro ( The schedule will be:
  • Tuesday (June 27th) evening - group dinner at at the 312 Chicago Restaurant.
  • Wednesday (June 28th) morning - plenary session with all three Councils and the entire Board
  • Wednesday afternoon - architecture council meeting 
  Tuesday 27 Wednesday 28 Thursday 29
am Requirements
(room: Joffrey Ballet)
Plenary w/ Board
(Steppenwolf A)
(Lyric Opera A)
pm Architecture
(Lyric Opera B)
eve Group Dinner
(Restaurant 321 (on-site))

The agenda for the Architecture Council is:
  • Eclipse Commons.
    One of the things that a number of projects and ecosystem have noticed is that (a) the tree of dependencies between Eclipse projects is wide and shallow and thus (b) if two projects want to share some code, it must be pushed into the platform project because that's the only common ground, even if the code in question is of absolutely no use in the platform itself. And this leads (c) to bloat within the platform, which does a great disservice to people in the community looking to use the platform to write lean and compact RCP apps.

    The idea of an Eclipse Commons project has been floated; the Architecture Council seems to be the place to discussion the goals of such a project.
    • Is this for EPL'd Eclipse plug-ins that are shared between projects?
    • Do projects graduate plug-ins into the commons? If not, where does the code come from?
    • Is this for Legal-approved third-party code, e.g., Apache logging, packaged as a plug-in?
    • What is the governance model for the Commons?
    • etc.

    Jeff McAffer is also interested in this issue and wrote up a proposal (attached below).
  • Eclipse Common Builds.
    To quote Rich: "[Common builds are] an inevitable next step and is related to the topic of an Eclipse Commons (who will build these projects?).  I doubt it will always be the case that what’s in commons is pre-built binaries. With that, it would seem logical that the base builder itself be maintained within commons and developed to support all Eclipse projects.  This topic was raised on a Callisto call and it was agreed that we could all benefit from a ‘build master summit’ to begin discussing what a new/improved base builder would look like."
  • JVM Version Changes.
    When should Eclipse move from requiring a 1.4 JVM to a 1.5 JVM? And what sort of process should we put in place for moving from version to version in the future?
  • Architecture Overlap.
    In general we have several areas in projects where projects are duplicating effort.  As a result we have overlapping architectures. As the Architecture Council, we should be actively dealing with this. What can we do? To be precise, what can we do that isn't just sitting around and talking, but will actually cause a reduction in overlap?
Look forward to seeing you there...

P.S. The next Council meetings will be in Stuttgart Oct 11-12 in conjunction with our first Eclipse Summit Europe.

Appendix A: Jeff's proposal:

The Eclipse Commons Project

An Eclipse Technology Project Proposal
June 2006

The Eclipse Commons Project is a proposed open source project under the Eclipse Technology Project.


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.

Bundlization: There are often several ways to "bundlize" 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 bundlized as one bundle or with a bundle for each JAR. In fact, libraries might not be bundlized at all but rather simply included in an existing bundle of the consuming project. Since each team performs this bundlization 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, ...), 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 bundlized, each team must duplicate the effort of bundlization and maintenance. Further, since the current approach is compartementalized, it often happens that project teams are unaware of the libraries used by one another. This results in gratuitous duplication of content in the Eclipse downloads (e.g., Callisto contains several copies of Xerces and commons logging, ...) 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 bundlized versions of existing libraries. Many systems built by others include the very same code. Again, these libraries are bundlized 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 bundlized 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 bundlization work for teams


This project will provide a repository of bundlized 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 bundlized third party libraries. This project will, as a mainline activity, provide a repository of approved and bundlized 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 bundlization 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 bundlization 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 the committers on this project will not be responsible for doing the bundlization 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 bundlized libraries are retained and made available within the project in various ways (e.g., download zip, update site, ...) for use in the projects that have received the appropriate approvals. Note teams seeking to use a library must still follow the IP process. For example, the current process calls or 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, ...) to manage library contribution requests and the libraries themselves.


This project will be organized into one top-level component :

  • Bundles : bundlization of libraries.

Proposed initial committers and project lead

The initial committers will be drawn from the Eclipse developer community and the Eclipse Foundation legal team. Developers with experience with , interest in, and/or an ongoing need for, shared code and bundlizing are potential committers on this project. The initial committers are:

  • Project lead????
  • Ward?
  • Bjorn?
  • Jeff McAffer (jeff_mcaffer@xxxxxxxxxx)
  • Pascal Rapicault (pascal_rapicault@xxxxxxxxxx) ???
  • <We will approach people in projects that are heavy users of thirdparty code (eg., WTP, DTP, ...) and encourage their participation>

Interested potential committers are kindly invited to express it on the newsgroup or via email.

Initial contribution

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.


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.

Back to the top