Eclipse MDT
Ganymede Plan

Last revised 17:59 EDT May 1, 2008 ( marks interesting changes over the previous plan revision)

Please send comments about this plan to the mdt-dev@eclipse.org developer mailing list.

This document lays out the feature and API set for the next feature release of the Eclipse MDT project, designated the Ganymede release.

Plans do not materialize out of nowhere, nor are they entirely static. To ensure the planning process is transparent and open to the entire Eclipse community, plans are posted in an embryonic form and then revised from time to time throughout the release cycle.

The first part of the plan deals with the important matters of release deliverables, release milestones, target operating environments, and release-to-release compatibility. These are all things that need to be clear for any release, even if no features were to change. 

The remainder of the plan consists of plan items for the components under the Eclipse MDT project. Each plan item covers a feature or API that is to be added, or some aspect that is to be improved. Each plan item has its own entry in the Eclipse bugzilla database, with a title and a concise summary (usually a single paragraph) that explains the work item at a suitably high enough level so that everyone can readily understand what the work item is without having to understand the nitty-gritty detail.

Not all plan items represent the same amount of work; some may be quite large, others, quite small. Some plan items may involve work that is localized to a single subsystem; others may involve coordinated changes across several projects within the same top-level project; and others may involve coordination with other top-level projects. Although some plan items are for work that is more pressing that others, the plan items appear in no particular order.

Fixing bugs, improving test coverage, documentation, examples, performance tuning, usability, etc. are considered routine ongoing maintenance activities and are not included in this plan unless they would also involve a significant change to the API or feature set, or involve a significant amount of work. The intent of the plan is to account for all interesting feature work.

The current status of each plan item is noted:

Release deliverables

The release deliverables are:

Release milestones

Release milestone occurring at roughly 6 week intervals exist to facilitate coarse-grained planning and staging. The milestones are:

The Ganymede release is targeted for late June 2008. All release deliverables will be available for download as soon as the release has been tested and validated in the target operating configurations listed below.

Target Operating Environments

In order to remain current, each release of an Eclipse project targets reasonably current versions of underlying operating environments and other Eclipse projects on which it depends. 

Most of Eclipse is "pure" JavaTM code and has no direct dependence on the underlying operating system. The chief dependence is on the Eclipse Platform, and on the Java 2 Platform that runs it.

The MDT Ganymede release depends on the following:

The Ganymede release of MDT is designed to run on any configuration supporting the above components.

The Eclipse Platform runs in a variety of operating environments. Testing is focused on a handful of popular combinations of operating system and Java 2 Platform; these are our reference platforms. Eclipse undoubtedly runs fine in many operating environments beyond the reference platforms we test. However, since we do not systematically test them we cannot vouch for them. Problems encountered when running Eclipse on non-reference platform that cannot be recreated on any reference platform will be given lower priority than problems with running Eclipse on a reference platform.

See the Eclipse Project 3.4 plan for a list of reference platforms.

Internationalization

Eclipse is designed as the basis for internationalized products. The user interface elements provided by the various Eclipse projects, including dialogs and error messages, are externalized. The English strings for MDT are provided as the default resource bundles. Translations are not provided with this release. However, the plug-in fragment mechanism provides the means by which translations into any number of other languages can be incorporated.

Compatibility with Previous Releases

Compatibility of OCL 1.2 with 1.1

The OCL 1.2 component of Eclipse MDT will be compatible with OCL 1.1, except in those areas noted in the OCL 1.2 Migration Guide.

API Contract Compatibility: OCL 1.2 will be upwards contract-compatible with OCL 1.1 except in those areas noted in the OCL 1.2 Migration Guide. Programs that use affected APIs and extension points will need to be ported to OCL 1.2 APIs. Downward contract compatibility is not supported. There is no guarantee that compliance with OCL 1.2 APIs would ensure compliance with OCL 1.1 APIs. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain contract compatibility.

Binary (plug-in) Compatibility: OCL 1.2 will be upwards binary-compatible with OCL 1.1 except in those areas noted in the OCL 1.2 Migration Guide. Downward plug-in compatibility is not supported: plug-ins compiled against OCL 1.2 will likely be unusable with OCL 1.1. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.

Source Compatibility: Source files written to use OCL 1.1 APIs will usually compile and run successfully against OCL 1.2 APIs, although this cannot be guaranteed. In some cases, it may be necessary to make minor changes to the source code to disambiguate things like imports or overloaded method invocations. Downward source compatibility is not supported. If source files use new APIs, they will not be usable with earlier versions.

Workspace Compatibility: OCL 1.2 will be upwards workspace-compatible with OCL 1.1 unless noted. This means that workspaces and projects created by an Eclipse with OCL 1.1 installed can be successfully opened by an Eclipse with OCL 1.2 installed. This includes both hidden metadata, which is localized to a particular workspace, as well as metadata files found within a workspace project, which may propagate between workspaces via file copying or team repositories. User interface session state may be discarded when a workspace is upgraded. Downward workspace compatibility is not supported. Metadata files created (or overwritten) by the newer version will generally be unusable with older versions.

Non-compliant usage of API's: All non-API methods and classes, and certainly everything in a package with "internal" in its name, are considered implementation details which may vary between operating environment and are subject to change without notice. Client plug-ins that directly depend on anything other than what is specified in the API are inherently unsupportable and receive no guarantees about compatibility within a single release much less with an earlier releases. Refer to How to Use the Eclipse API for information about how to write compliant plug-ins.

Compatibility of UML2 2.2 with 2.1

The UML2 2.2 component of Eclipse MDT will be compatible with UML2 2.1, except in those areas noted in the UML2 2.2 Migration Guide.

API Contract Compatibility: UML2 2.2 will be upwards contract-compatible with UML2 2.1 except in those areas noted in the UML2 2.2 Migration Guide. Programs that use affected APIs and extension points will need to be ported to UML2 2.2 APIs. Downward contract compatibility is not supported. There is no guarantee that compliance with UML2 2.2 APIs would ensure compliance with UML2 2.1 APIs. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain contract compatibility.

Binary (plug-in) Compatibility: UML2 2.2 will be upwards binary-compatible with UML2 2.1 except in those areas noted in the UML2 2.2 Migration Guide. Downward plug-in compatibility is not supported: plug-ins compiled against UML2 2.2 will likely be unusable with UML2 2.1. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.

Source Compatibility: Source files written to use UML2 2.1 APIs will usually compile and run successfully against UML2 2.2 APIs, although this cannot be guaranteed. In some cases, it may be necessary to make minor changes to the source code to disambiguate things like imports or overloaded method invocations. Downward source compatibility is not supported. If source files use new APIs, they will not be usable with earlier versions.

Workspace Compatibility: UML2 2.2 will be upwards workspace-compatible with UML2 2.1 unless noted. This means that workspaces and projects created by an Eclipse with UML2 2.1 installed can be successfully opened by an Eclipse with UML2 2.2 installed. This includes both hidden metadata, which is localized to a particular workspace, as well as metadata files found within a workspace project, which may propagate between workspaces via file copying or team repositories. User interface session state may be discarded when a workspace is upgraded. Downward workspace compatibility is not supported. Metadata files created (or overwritten) by the newer version will generally be unusable with older versions.

Non-compliant usage of API's: All non-API methods and classes, and certainly everything in a package with "internal" in its name, are considered implementation details which may vary between operating environment and are subject to change without notice. Client plug-ins that directly depend on anything other than what is specified in the API are inherently unsupportable and receive no guarantees about compatibility within a single release much less with an earlier releases. Refer to How to Use the Eclipse API for information about how to write compliant plug-ins.

Compatibility of UML2 Tools 0.8 with 0.7

The UML2 Tools 0.8 component of Eclipse MDT will be compatible with UML2 Tools 0.7, except in those areas noted in the UML2 Tools 0.8 Migration Guide.

API Contract Compatibility: UML2 Tools 0.8 will be upwards contract-compatible with UML2 Tools 0.7 except in those areas noted in the UML2 Tools 0.8 Migration Guide. Programs that use affected APIs and extension points will need to be ported to UML2 Tools 0.8 APIs. Downward contract compatibility is not supported. There is no guarantee that compliance with UML2 Tools 0.8 APIs would ensure compliance with UML2 Tools 0.7 APIs. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain contract compatibility.

Binary (plug-in) Compatibility: UML2 Tools 0.8 will be upwards binary-compatible with UML2 Tools 0.7 except in those areas noted in the UML2 Tools 0.8 Migration Guide. Downward plug-in compatibility is not supported: plug-ins compiled against UML2 Tools 0.8 will likely be unusable with UML2 Tools 0.7. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.

Source Compatibility: Source files written to use UML2 Tools 0.7 APIs will usually compile and run successfully against UML2 Tools 0.8 APIs, although this cannot be guaranteed. In some cases, it may be necessary to make minor changes to the source code to disambiguate things like imports or overloaded method invocations. Downward source compatibility is not supported. If source files use new APIs, they will not be usable with earlier versions.

Workspace Compatibility: UML2 Tools 0.8 will be upwards workspace-compatible with UML2 Tools 0.7 unless noted. This means that workspaces and projects created by an Eclipse with UML2 Tools 0.7 installed can be successfully opened by an Eclipse with UML2 Tools 0.8 installed. This includes both hidden metadata, which is localized to a particular workspace, as well as metadata files found within a workspace project, which may propagate between workspaces via file copying or team repositories. User interface session state may be discarded when a workspace is upgraded. Downward workspace compatibility is not supported. Metadata files created (or overwritten) by the newer version will generally be unusable with older versions.

Non-compliant usage of API's: All non-API methods and classes, and certainly everything in a package with "internal" in its name, are considered implementation details which may vary between operating environment and are subject to change without notice. Client plug-ins that directly depend on anything other than what is specified in the API are inherently unsupportable and receive no guarantees about compatibility within a single release much less with an earlier releases. Refer to How to Use the Eclipse API for information about how to write compliant plug-ins.

Compatibility of XSD 2.4 with 2.3

The XSD 2.4 component of Eclipse MDT will be compatible with XSD 2.3, except in those areas noted in the XSD 2.4 Migration Guide.

API Contract Compatibility: XSD 2.4 will be upwards contract-compatible with XSD 2.3 except in those areas noted in the XSD 2.4 Migration Guide. Programs that use affected APIs and extension points will need to be ported to XSD 2.4 APIs. Downward contract compatibility is not supported. There is no guarantee that compliance with XSD 2.4 APIs would ensure compliance with XSD 2.3 APIs. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain contract compatibility.

Binary (plug-in) Compatibility: XSD 2.4 will be upwards binary-compatible with XSD 2.4 except in those areas noted in the XSD 2.4 Migration Guide. Downward plug-in compatibility is not supported: plug-ins compiled against XSD 2.4 will likely be unusable with XSD 2.3. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.

Source Compatibility: Source files written to use XSD 2.3 APIs will usually compile and run successfully against XSD 2.4 APIs, although this cannot be guaranteed. Because XSD 2.4 may exploit new Java language constructs, there is an increased chance of source incompatibilities compared to previous XSD releases. In some cases, it may be necessary to make minor changes to the source code to disambiguate things like imports or overloaded method invocations. Downward source compatibility is not supported. If source files use new APIs, they will not be usable with earlier versions.

Workspace Compatibility: XSD 2.4 will be upwards workspace-compatible with XSD 2.3 unless noted. This means that workspaces and projects created by an Eclipse with XSD 2.3 installed can be successfully opened by an Eclipse with XSD 2.4 installed. This includes both hidden metadata, which is localized to a particular workspace, as well as metadata files found within a workspace project, which may propagate between workspaces via file copying or team repositories. User interface session state may be discarded when a workspace is upgraded. Downward workspace compatibility is not supported. Metadata files created (or overwritten) by the newer version will generally be unusable with older versions.

Non-compliant usage of API's: All non-API methods and classes, and certainly everything in a package with "internal" in its name, are considered implementation details which may vary between operating environment and are subject to change without notice. Client plug-ins that directly depend on anything other than what is specified in the API are inherently unsupportable and receive no guarantees about compatibility within a single release much less with an earlier releases. Refer to How to Use the Eclipse API for information about how to write compliant plug-ins.

Themes

The changes under consideration for the next release of Eclipse MDT align with themes identified by the Eclipse Requirements Council and Modeling project.

OCL component

OCL is an implementation of the OCL OMG standard for EMF-based models. Plan items reflect new features of the OCL component, or areas where existing features will be significantly reworked ( marks completed work).

Committed Items (OCL component)

Extending the OCL grammar for QVT. Grammar/parser refactorings for improved extensibility, especially targeting QVT implementations. (176110) [Theme: End-to-End MDSD]

Navigation of unnamed association ends. Navigation of unnamed association ends (for UML models) (194245) [Theme: End-to-End MDSD]

Customising error handling. Redesign of parse error detection for better error reporting. (176110) [Theme: Improved Usability]

Proposed Items (OCL component)

None at this time.

Deferred Items (OCL component)

None at this time.

UML2 component

UML2 is an EMF-based implementation of the UMLTM 2.x metamodel for the Eclipse platform. Plan items reflect new features of the UML2 component, or areas where existing features will be significantly reworked ( marks completed work).

Committed Items (UML2 component)

Profile Support for Ecore Annotations. Because there is no general GUI support for specifying EAnnotations (since they aren't a standard part of UML) users currently cannot specify the EAnnotations they'd like to see in the final Ecore, so it would be very useful if as part of the Ecore profile, they'd be able to create EAnnotations. (184249) [Theme: End-to-End MDSD]

Support for (de)serialization to/from CMOF. Provide a resource implementation that supports loading/saving UML models in CMOF format in much the same way that EMF supports loading/saving Ecore models in EMOF format. Such support should be integrated into the sample UML editor and importer framework (to allow creating of EMF projects from CMOF models).better diagnostics for unresolved directives. (199624) [Theme: End-to-End MDSD]

Eclipse 3.4 / EMF 2.4 Compatibility. Maintain release currency concurrent with EMF 2.4 (and Eclipse 3.4). Make changes as required to align with EMF features and bug fixes. (204200) [Theme: Upgrade Path]

Enhanced Documentation. Provide enhanced user documentation, tutorials, white papers, demonstrations etc.. In particular, provide a programmer’s guide integrated with the help system in Eclipse, improve the Javadoc by generating constraint information (redefines, subsets, union, etc.) into feature and operation headers, and update the documentation for the UML generator task. (204201) [Theme: Ease of Use]

UML 2.1.2 Compliance. Provide support for interchange (XMI) compliance with UML 2.1.2. (204202) [Theme: Technology Trends]

Proposed Items (UML2 component)

None at this time.

Deferred Items (UML2 component)

BiDi Support. Provide better support for BiDi languages. (160682) [Theme: Internationalization & Localization]

UML2 Tools component

UML2 Tools is set of GMF-based editors for viewing and editing UML models. Plan items reflect new features of the UML2 Tools component ( marks completed work).

Committed Items (UML2 Tools component)

Composite Structure Diagrams. Provide a GMF-based editor for UML composite structure diagrams. (199723) [Theme: End-to-End MDSD]

Deployment Diagrams. Provide a GMF-based editor for UML deployment diagrams. (199724) [Theme: End-to-End MDSD]

Use Case Diagrams. Provide a GMF-based editor for UML use case diagrams. (199725) [Theme: End-to-End MDSD]

Object Diagrams. Provide a GMF-based editor for UML object diagrams. (199726) [Theme: End-to-End MDSD]

Structure Diagram Synchronization. For structure diagrams it makes sense to provide customizable level of synchronization between semantic and notational models; in particular, instead of auto-synchronized class diagrams (which always show the complete contents of the semantic model), different levels of synchronization should be also supported. (199731) [Theme: Improved Usability]

Diagram Relations. With extended set of 8 diagram types (4 implemented in 0.7 and 4 planned for the next release) it is essential to provide collaboration of the different diagram types in showing the different set of aspects for the single semantic model. (199735) [Theme: Improved Usability]

Basic OCL Integration. Integrate the features provided by OCL component with UML2Tools diagrams, allowing to write/validate/etc OCL expressions in terms of given semantic model, shown in the diagram. (199737) [Theme: End-to-End MDSD]

Extended Profile Support. Diagram features like choosers, inplace editors, label providers, creation tools, etc., should be at some extent aware of the constraints implied by profiles applied to the semantic model. (199739) [Theme: Improved Usability]

Diagram-Specific Property Sheets. Provide custom, extensible property sheets that are aware of the UML2 Tools arrangement of the semantic elements into notational diagrams. (199740) [Theme: Improved Usability]

Proposed Items (UML2 Tools component)

None at this time.

Deferred Items (UML2 Tools component)

None at this time.

XSD component

XSD is a library that provides an API for manipulating the components of an XML Schema as described by the W3C XML Schema specifications, as well as an API for manipulating the DOM-accessible representation of XML. Plan items reflect new features of the XSD component, or areas where existing features will be significantly reworked ( marks completed work).

Committed Items (XSD component)

Improved Diagnostics. Provide better diagnostics for unresolved directives. (203607) [Theme: Ease of Use]

Proposed Items (XSD component)

None at this time.

Deferred Items (XSD component)

XML Schema 1.1. Investigate support for XML Schema 1.1. (204125) [Theme: Technology Trends]