Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[] Council meetings next week

Title: Bjorn Freeman
Architecture Council Members, (with a cc to Todd, Rich, and Howard)
My apologies for the tardiness of this agenda and for the fact that I still haven't posted the minutes from our last meeting in August.

The schedule for the meetings returns to the "Portland style":

  Tuesday 13 Wednesday 14 Thursday 15
am Requirements   Plenary w/ Board Planning
pm Architecture 1/2 Architecture 2/2
eve Group dinner w/ Board    

You've all already made hotel reservations, but just in case you forgot where it is, the hotel is the Serrano Hotel, 405 Taylor Street, San Francisco

I have these goals for the Architecture Council next week: [leader]
  1. [All] Choose a time for monthly Architecture Council calls. Our calls to date have been sporadic and, to be honest, not that useful. However, there is a theory that if we get in the habit of regular monthly conference calls, our interactions and collaborations will increase. Let's try it for six months and then either it will be successful or we'll give up.
  2. [Harm] Discuss tools and suggestions for UI-based Eclipse testing. Tim says that BEA uses Abbott plus some homegrown extensions. Rich says Borland uses some homegrown tools. Harm says that TPTP uses a UI macro record-playback tool from the PDE folks and that he'd be happy to demo it for the AC.
  3. [Kevin] Status report from Kevin on the effort to use new Eclipse wiki ( to create user interface guidelines as an improved version of the existing old Platform team UI guidelines - how many projects have expressed interest/have joined the effort?
  4. [Kevin] Status report from Kevin on Activities and Activity Categories for progressive disclosure. Kevin was going to send the documentation to our mailing list (but I can't really complain about it not happening because I still haven't posted the minutes from three months ago).
  5. [All] Draft the architecture contribution to the Roadmap v2.0.
I had an Action Item from the last call to invite the Plug-in Member Representatives to our meeting so that they could tell us what they would like to see in the Roadmap. Unfortunately, the Board meeting with be held on Tuesday so they are unable to attend on Tuesday. I have cc'd them on this email hoping that they will be able to join us on Wednesday afternoon, but I already have confirmation from one of them that his schedule does not allow it.

Attached are suggested views of the Eclipse architectures from Anurag and Kai, and a suggested Roadmap format from Rich.

Group Dinner Tuesday Night
1830 cocktails, 1900 dinner at the Ponzu Restaurant (at the hotel). Those of you who pre-registered for dinner know who you are. Those of you who didn't - well, there aren't any seats left in the dining area, sorry.

Plenary Session Wednesday Morning
0800 - 0830: Continental Breakfast
0830 - 1000: Steven O'Grady (Redmonk): Building Communities
1000 - 1015: Break
1015 - 1100: Topic Leader: Mike Norman
I'm very interested in interoperability amongst projects, not just in terms of interop through the platform, but interop with each other.  There are related issues of re-use, packaging, release trains, quality etc.  There's a balance to be struck between a top-down and a bottom-up model. This is something that I think would be a useful area for the board to flesh out a policy.  However, it's not really for EMO execution, more something that is in scope of the Councils, so it ends up back with the member organizations, with EMO facilitation.
1100 - 1200: Topic Leader: Bjorn Freeman-Benson
Currently, the Board and the Projects see the development process differently. The Board wants protection; the Projects want freedom; each side needs to understand that there is value in the other's view and that some middle ground is going to be the best solution.
Bjorn Freeman-Benson
Director, Open Source Process
Eclipse Foundation
voice:  971-327-7323 (PST, UTC-8)
email:  bjorn.freeman-benson@xxxxxxxxxxx

Title: Eclipse Roadmap Architecture Plan

Eclipse Architecture Plan

This plan has been developed in accordance with the Eclipse Development Process and is included as part of the Eclipse Roadmap. As stated in the development process, the "Architecture Council produces an Architecture Plan that describes the architecture changes required to achieve these themes and priorities, or required to maintain long-term architectural viability."

Also in accordance with the process, the Architecture Plan contains the following information: changes to architectural interfaces, the impact of these changes, and the order in which these changes should be implemented; new subsystems that should be created; subsystems that should be combined; and, conformance with industry standards.

In order to provide this information, this document is arranged into the following sections:
 Project View
 Logical View
 Noteworthy Items
 Industry Standards

Project View

The Eclipse community is organized into eight top-level projects, each of which has provided its detailed architecture using the links below. Additionally, each includes a link to plan items related to architecture for their upcoming release. Alternatively, to navigate to each project using an image map, click here: Click to navigate projects via image map...

Project Current Architecture Architecture Plan
Platform Project Architecture documents... Architecture plan...
Tools Project Architecture documents... Architecture plan...
Test and Performance Tools Platform Project Architecture documents... Architecture plan...
Web Tools Platform Project Architecture documents... Architecture plan...
Business Intelligence and Reporting Tools Project Architecture documents... Architecture plan...
Data Tools Platform Project Architecture documents... Architecture plan...
Device Software Development Platform Project Architecture documents... Architecture plan...
Technology Project Architecture documents... Architecture plan...

Logical View

While the project structure indicates the team structure for contribution effort, it is also helpful to view a logical grouping of functionality found at Eclipse. This view indicates what logical components exist, areas of ongoing work or refactoring, and areas where new functionality is required.

[If we can agree on what this diagram should contain, I can define/generate it using GMF]

Noteworthy Items

A number of noteworthy items from the ongoing and planned work are listed here for convenience. These items have significant architectural or API impact, crosscut project boundaries, or otherwise are critical to the community.

Item Detail
Refactor the runtime The Eclipse runtime is currently one monolithic plugin that contains the extension registry, jobs, preferences, content types, application model and various helper/utility classes.  Various use cases demand independent use of these facilities.  The runtime should be refactored into individual bundles for the different functional areas to improve the support for specific use cases such as using the extension registy on standard OSGi systems or standalone, and better integration between the Eclipse application model and OSGi (e.g., the OSGi MEG application model).
Project Facets This framework provides a common mechanism and ui for adding and removing units of functionality from a project. A unit of functionality (or a "feature") is a marker that can be used, for instance, to enable feature-specific UI. A feature also has a great deal of flexibility to manipulate the project when it's being installed. It can add natures, builders, and classpath entries. It can also lay down feature-specific metadata files and other resources into the project directory.
Logical Model Integration The Eclipse Platform supports a strong physical view of projects containing resources (files and folders) in the workspace. However, there are many situations where plug-in developers would prefer to work with a logical model that is appropriate to their domain. Eclipse should ease the task for plug-in developers who want to make logical model-aware plug-ins. To do this, Eclipse should provide more flexible mechanisms for contributing actions on models that do not have a one-to-one mapping to files on the users hard disk. This would, for example, allow a team provider's repository operations to be made available on logical artifacts. In addition, existing views like the navigator and problems view should be generalized to handle logical artifacts and, in general, there should be better control over what is displayed in views and editors based on the logical models that the end user is working on.
Increased Workspace Flexibility Currently in Eclipse there is a direct connection between IResources and files and directories on the local file system. Eclipse should loosen this connection, by abstracting out its dependency on, and allowing for alternative implementations. This would enable, for example, uses where the workspace is located on a remote server, or accessed via a non-file-based API, or has a non-trivial mapping between the resources and the physical layout of the files.
Increased RCP Development Flexibility The Eclipse text editor should better support RCP applications, by making features like the following available to them: annotation presentation and navigation, user assigned colors and fonts, spell checking, folding, quick diff, templates, and file buffers. The Eclipse workbench layout should be further opened up to allow RCP applications to have more control over its presentation.
Others... Add more here, but only those the AC considers truly "Noteworthy"

Industry Standards

The Eclipse community has strong support for industry standards and has plans to strengthen this support as indicated by this list of initiatives:

Standard Status
OSGi The Platform's Equinox project team is working toward...
Unified Modeling Language (UML) The Tools project UML2 project...
More... There are a lot more standards, as well as Section 508 compliance, ICU4J, etc. that could be detailed here. Perhaps something other than "Industry Standards" would be better?


The following items are recommended by the Architecture Council for consideration by project teams, or by the formation of a new project, in order to "to maintain long-term architectural viability" of Eclipse:

Insert recommendations here... The idea is that there are some things missing from Eclipse that can be called out here, in addition to issues discussed at quarterly meetings that require cross-project cooperation.

Architecture Plan Reference Information More...

  • Quality API
    This document outlines what a "Quality API" is and how APIs are maintained and documented at Eclipse.
  • API Issues
    This report lists those issues related to API that are underway or planned for this edition of the Architecture Roadmap.
  • Architectural Issues
    I can imagine there are no shortage of links to provide here...

Attachment: Anurag.ppt
Description: MS-Powerpoint presentation

Attachment: Kai.ppt
Description: MS-Powerpoint presentation

Back to the top