Architecture Council Members,
As you know, the Q2 council meetings are being held in Chicago at the Hotel Allegro (www.allegrochicago.com).
The schedule will be:
- Tuesday (June 27th)
evening - group dinner at at the 312 Chicago
- Wednesday (June 28th)
morning - plenary session with all three Councils and the entire Board
- Wednesday afternoon -
architecture council meeting
(room: Joffrey Ballet)
|Plenary w/ Board
(Lyric Opera A)
(Lyric Opera B)
(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
- 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?
Jeff McAffer is also interested in this issue and wrote up a proposal
Look forward to seeing you there...
- 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
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?
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
The Eclipse Commons Project is a proposed open source project under
the Eclipse Technology
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
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
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
- Project lead????
- 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
Interested potential committers are kindly invited to express it on
the newsgroup or via email.
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