Eclipse Architecture Council Minutes
June 28, Chicago, Illinois
|no data||no data|
Minutes / Discussion Items
(these notes are in logical rather than chronological order)
Discussion about what JVM version will be required/supported by Europa. Some of the points included: is Eclipse going to be a 1.4 application and not move to 1.5? Perhaps the statement is that "Eclipse is a framework built around 1.4"? How do we respond to "you are no longer cool because you are stuck on 1.4"? (if we choose that) The problem is, of course, that 1.5 is really a new language (but 1.6 is not).
Projects should tell their dependencies what the project's JVM requirements are so that the dependent projects can either concur or push back. The Platform will continue to run on JVM 1.4 but if you run on 1.5 you will get additional features. Moving to 1.5 is not mandatory; execution can move; new plug-ins can move to 1.5 features. Our goal is to have both a smaller 1.4 version and to support all the new features of 1.5 - i.e., the best of both worlds. Our goal is no gratuitous 1.5 - go ahead and use 1.5 where necessary. Document it. Specify it in the manifest file.
ACTION: [Ed Merks, Michael Scharf] draft the initial wiki page describing the implications of changing to 1.5.
ACTION: [All] All projects should have a statement in their project plan about their position on 1.5.
We briefly discussed the fact that the Architecture Council should provide guidelines for developers about multi-core-safe and then multi-core-utilizing programs.
Common Build Infrastructure
We discussed build infrastructure and the question of why are all the projects doing our own specialized build systems and scripts? This makes coordination hard. For example, version number ranges - Ed explained why he doesn't want to do it manually. He has a script that computes it as part of his builder. People should use a common build infrastructure, but we should probably not require it. We should require certain interface/API characteristics, such as an RSS feed. Some projects (such as BIRT) find the RSS to be a low priority because they build on a schedule rather than no notification.
Reasons for a common build infrastructure:
- To get it right
- Go to someone else's project and build it
Kevin says "any automation for this stuff is good".
We don't want to force too much conformity because that stops innovation; alternately, conformity in the base allows innovation higher up. Another argument is that innovation at the build system should not be being done.
We should have a build teams get-together for social, technical, and requirements gathering. Ward offered that the Portland Eclipse team would be happy to arrange/host that. This gathering should be assembled with some sort of direction - what would that be? AC members should gather the problems their build teams are having, and the features their build systems have: "Pain and Pride". Optionally a wishlist.
We had a goal of doing this by July 20 but because the minutes were not published until September, that didn't happen.
We also discussed common shaped (directories and files) build results? Perhaps our common build system can also have some evaluation tools (such as checking for overlapping third-party library versions) that could help with Europa. This proposal is about Europa build support, not about the Eclipse Foundation common build system for small/all projects. If the Eclipse Foundation wanted to offer that feature, it would have to supply its own people/machines/resources and release engineers to help.
Jeff describes his proposal. Also a best practices recommendations. We got side-tracked a bit on the legal issues of whether each project would need to get legal approval to depend on the commons plug-ins and if so, whether it could get approval for version * instead of version 1.6 (e.g.). We went off in another direction for a while on the granularity of features versus plug-ins versus update manager. This is definitely topic for the next council meeting.
Questions (and some answers):
- Why do this Commons project? To expose and control dependencies.
- How would we deal with the source of these things?
- For third-party only or for sharing common bits of Eclipse as well? Let's start with third-party only. We can evolve it over time and to start with this. "Commons" is not quite the right name; something about "Third-Party" might be better.
When polled, the room was all positive. Jeff volunteered as the project lead. All the teams that contribute third-party bundles would have committers on the project.
Notes taken and posted by Bjorn Freeman-Benson