Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [] November 8 conference callminutes



I have attached an outline of what I believe the Architecture Plan could look like, if what is currently posted were augmented with more of what’s called for in the Development Process, and our recent discussion of a “logical” view.


Just some thoughts, really… and perhaps something to work from when we meet next week.


Best Regards,



Richard C. Gronback

Borland Software Corporation


+1 860 227 9215



From: [] On Behalf Of Bjorn Freeman-Benson
Sent: Thursday, November 24, 2005 1:22 PM
Subject: [] November 8 conference callminutes


    Bjorn Freeman-Benson
    Kai Nyman
    Richard Gronback
    Kevin Haaland
    Wenfeng Li
    Stefan Daume
    Michael Scharf

    John Graham
    Harm Sluiman

    John Duimovich
    Anurag Gupta
    Boris Kapitanski
    Tim Wagner
    John Wiegand
    David Williams
    Alan Young


We set some goals for what the Architecture Council contribution to the Roadmap 2.0 should look like. Our low bar is that whatever we put in the document must be accurate. (Clearly the empty set is accurate; that's why this is the low bar.)  We also agreed that the primary reason we are writing the Architecture portion of the Roadmap so that the ISV community can understand what is in Eclipse and how it is put together. The secondary reason is to help each other (the other Eclipse projects) understand how the pieces fit together.

We discussed a bit about whether the Coarse-grained architecture vs fine-grained architecture

Action Item: [Bjorn] Have the plug-in dev representatives show up at the AC meeting to tell us what their requirements are?

We plan to start the draft at our December meeting, to complete the draft by January 15th, and to send the final version (of our portion) to the Board on January 31st. We acknowledge that this will take a certain diligent effort on our part and we have committed to do this.

Action Item: [Kai] Wants a better picture of the architecture and will send an email around explaining what an alternative picture would be.

Action Item: [All] Review the old roadmap document and send email to all about where it is inaccurate and where it is incomplete.


We suggested to ourselves that we should use the new Eclipse wiki ( to create user interface guidelines as an improved version of the existing old Platform team UI guidelines.

Action Item: [All] send Kevin an email saying that you are interested and work on it


All the Callisto projects need to make sure they support Activities and Activity Categories for progressive disclosure. It is important to do this now so that the Platform team can add new trigger points if they prove to be necessary. Kevin explained about trigger points and how if your features are hidden (because the Activity Category is hidden) and there is no trigger point to make it visible, then you can never get to it. They had one case involving something about team support, so there might be other cases and it would be better to find them now rather than later.

Action Item: [Kevin] will send the documentation to the mailing list


Action Item: [All] everyone come to December meetings ready to discuss and negotiate for the call dates for Q1 and Q2.

Which reminds me - very few people made hotel registrations for the December council meetings. I'm hoping that you are planning to be there in San Francisco in a couple weeks...

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...

Back to the top