DRAFT Eclipse MDT
1.1 Plan

Last revised 15:36 EDT July 24, 2007 ( 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 release 1.1.

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:

  • Committed plan item – A committed plan item is one that we have decided to address for the release.
  • Proposed plan item – A proposed plan item is one that we are considering addressing for the release. Although we are actively investigating it, we are not yet in a position to commit to it, or to say that we won’t be able to address it. After due consideration, a proposal will either be committed or deferred.
  • Deferred plan item – A reasonable proposal that will not make it into this release for some reason is marked as deferred with a brief note as to why it was deferred. Deferred plan items may resurface as committed plan items at a later point.

Release deliverables

The release deliverables are:

  • Source code release for the EODM component, available as versions tagged "R1_0" in the eclipse.org CVS repository.
  • EODM runtime binary and SDK distributions (downloadable).
  • EODM runtime binary and SDK features on eclipse.org update site (install via Eclipse update manager).
  • Source code release for the OCL component, available as versions tagged "R1_2" in the eclipse.org CVS repository.
  • OCL runtime binary and SDK distributions (downloadable).
  • OCL runtime binary and SDK features on eclipse.org update site (install via Eclipse update manager).
  • Source code release for the UML2 component, available as versions tagged "R2_2" in the eclipse.org CVS repository.
  • UML2 runtime binary and SDK distributions (downloadable).
  • UML2 runtime binary and SDK features on eclipse.org update site (install via Eclipse update manager).
  • Source code release for the UML2 Tools component, available as versions tagged "R0_8" in the eclipse.org CVS repository.
  • UML2 Tools runtime binary and SDK distributions (downloadable).
  • UML2 Tools runtime binary and SDK features on eclipse.org update site (install via Eclipse update manager).
  • Source code release for XSD component, available as versions tagged "R2_4" in the eclipse.org CVS repository.
  • XSD runtime binary and SDK distributions (downloadable).
  • XSD runtime binary and SDK features on eclipse.org update site (install via Eclipse update manager).

Release milestones

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

The 1.1 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 1.1 release depends on the following:

  • Java 2 Platform 1.5
  • Eclipse Platform 3.4
  • EMF 2.4
  • GMF 2.1

The 1.1 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 EODM 1.0 with 0.9

The EODM 1.0 component of Eclipse MDT will be compatible with EODM 0.9, except in those areas noted in the EODM 1.0 Migration Guide.

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

Binary (plug-in) Compatibility: EODM 1.0 will be upwards binary-compatible with EODM 0.9 except in those areas noted in the EODM 1.0 Migration Guide. Downward plug-in compatibility is not supported: plug-ins compiled against EODM 1.0 will likely be unusable with EODM 0.9. 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 EODM 0.9 APIs will usually compile and run successfully against EODM 1.0 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: EODM 1.0 will be upwards workspace-compatible with EODM 0.9 unless noted. This means that workspaces and projects created by an Eclipse with EODM 0.9 installed can be successfully opened by an Eclipse with EODM 1.0 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 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.

EODM component

EODM is an implementation of RDF(S)/OWL metamodels of the Ontology Definition Metamodel (ODM) using EMF with additional parsing, inference, model transformation and editing functions. Plan items reflect new features of the EODM component, or areas where existing features will be significantly reworked ( marks completed work).

Committed Items (EODM component)

None at this time.

Proposed Items (EODM component)

None at this time.

Deferred Items (EODM component)

None at this time.

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)

None at this time.

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)

None at this time.

Proposed Items (UML2 component)

None at this time.

Deferred Items (UML2 component)

None at this time.

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)

None at this time.

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)

None at this time.

Proposed Items (XSD component)

None at this time.

Deferred Items (XSD component)

None at this time.