| RE: [eclipse.org-architecture-council] November 8 conference callminutes |
|
Hello, 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, Rich Richard
C. Gronback Borland Software Corporation +1 860 227 9215 From: Attending: |
|
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 | |
| Recommendations |
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:
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]
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 java.io.File, 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" |
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. |