Eclipse MDT
1.0 Plan

Last revised 15:00 EDT July 5, 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.0.

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 "R0_9" 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_1" 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_1" 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_7" 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_3" 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:

  • Thursday, November 16 – Milestone 3 (1.0 M3) – Stable Build based on Eclipse 3.3 M3
  • Thursday, January 4 – Milestone 4 (1.0 M4) – Stable Build based on Eclipse 3.3 M4
  • Friday, February 23 – Milestone 5 (1.0 M5) – Stable Build based on Eclipse 3.3 M5
  • Friday, April 6 – Milestone 6 (1.0 M6) – API Freeze – Stable Build based on Eclipse 3.3 M6
  • Friday, May 18 – Milestone 7 (1.0 RC0) – Stable Build based on Eclipse 3.3 RC0

The 1.0 release is targeted for late June 2007. 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.0 release depends on the following:

  • Java 2 Platform 1.5
  • Eclipse Platform 3.3
  • EMF 2.3
  • GMF 2.0

The 1.0 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.3 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 0.9 with 0.7

The EODM 0.9 component of Eclipse MDT will not be compatible with EODM 0.7.

API Contract Compatibility: EODM 0.9 will not be upwards contract-compatible with EODM 0.7 as noted in the EODM 0.9 Migration Guide. Programs that use affected APIs and extension points will need to be ported to EODM 0.9 APIs. Downward contract compatibility is not supported. Compliance with EODM 0.9 APIs would not ensure compliance with EODM 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: EODM 0.9 will not be upwards binary-compatible with EODM 0.7 as noted in the EODM 0.9 Migration Guide. Downward plug-in compatibility is not supported: plug-ins compiled against EODM 0.9 will be unusable with EODM 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 EODM 0.7 APIs will not compile and run successfully against EODM 0.9 APIs. 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 0.9 will not be upwards workspace-compatible with EODM 0.7 as noted. This means that workspaces and projects created by an Eclipse with EODM 0.7 installed cannot be successfully opened by an Eclipse with EODM 0.9 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.1 with 1.0

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

API Contract Compatibility: OCL 1.1 will be upwards contract-compatible with OCL 1.0 except in those areas noted in the OCL 1.1 Migration Guide. Programs that use affected APIs and extension points will need to be ported to OCL 1.1 APIs. Downward contract compatibility is not supported. There is no guarantee that compliance with OCL 1.1 APIs would ensure compliance with OCL 1.0 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.1 will be upwards binary-compatible with OCL 1.0 except in those areas noted in the OCL 1.1 Migration Guide. Downward plug-in compatibility is not supported: plug-ins compiled against OCL 1.1 will likely be unusable with OCL 1.0. 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.0 APIs will usually compile and run successfully against OCL 1.1 APIs, although this cannot be guaranteed. Because OCL 1.1 may exploit new Java language constructs and/or aspects of the OCL specification, there is an increased chance of source incompatibilities compared to previous OCL 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: OCL 1.1 will be upwards workspace-compatible with OCL 1.0 unless noted. This means that workspaces and projects created by an Eclipse with OCL 1.0 installed can be successfully opened by an Eclipse with OCL 1.1 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.1 with 2.0

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

API Contract Compatibility: UML2 2.1 will be upwards contract-compatible with UML2 2.0 except in those areas noted in the UML2 2.1 Migration Guide. Programs that use affected APIs and extension points will need to be ported to UML2 2.1 APIs. Downward contract compatibility is not supported. There is no guarantee that compliance with UML2 2.1 APIs would ensure compliance with UML2 2.0 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.1 will be upwards binary-compatible with UML2 2.0 except in those areas noted in the UML2 2.1 Migration Guide. Downward plug-in compatibility is not supported: plug-ins compiled against UML2 2.1 will likely be unusable with UML2 2.0. 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.0 APIs will usually compile and run successfully against UML2 2.1 APIs, although this cannot be guaranteed. Because UML2 2.1 may exploit new Java language constructs, there is an increased chance of source incompatibilities compared to previous UML2 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: UML2 2.1 will be upwards workspace-compatible with UML2 2.0 unless noted. This means that workspaces and projects created by an Eclipse with UML2 2.0 installed can be successfully opened by an Eclipse with UML2 2.1 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.3 with 2.2

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

API Contract Compatibility: XSD 2.3 will be upwards contract-compatible with XSD 2.2 except in those areas noted in the XSD 2.3 Migration Guide. Programs that use affected APIs and extension points will need to be ported to XSD 2.3 APIs. Downward contract compatibility is not supported. There is no guarantee that compliance with XSD 2.3 APIs would ensure compliance with XSD 2.2 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.3 will be upwards binary-compatible with XSD 2.3 except in those areas noted in the XSD 2.3 Migration Guide. Downward plug-in compatibility is not supported: plug-ins compiled against XSD 2.3 will likely be unusable with XSD 2.2. 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.2 APIs will usually compile and run successfully against XSD 2.3 APIs, although this cannot be guaranteed. Because XSD 2.3 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.3 will be upwards workspace-compatible with XSD 2.2 unless noted. This means that workspaces and projects created by an Eclipse with XSD 2.2 installed can be successfully opened by an Eclipse with XSD 2.3 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)

Standard Compliance. Provide a new API that is compliant with the (to be adopted) 5th submission of the ODM specification to the OMG. (162682) [Theme: Appealing to a Broader Community]

Dynamic Typing. Provide support for dynamic typing. (162683) [Theme: Appealing to a Broader Community]

RDF/OWL Parsing and Serialization. Provide support for RDF/OWL parsing and serialization. (162684) [Theme: Appealing to a Broader Community]

RDF/OWL Reasoning. Provide support for RDF/OWL reasoning. (162685) [Theme: Appealing to a Broader Community]

RDF/OWL Transformation to/from Ecore. Provide a mechanism to transform RDF/OWL models to/from Ecore. (162686) [Theme: Cohesion]

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)

Parsing API. Provide a public API for parsing OCL documents, with the complete context declaration syntax. (144210) [Theme: Design for Extensibility – Be a Better Platform]

Integration with UML. Provide support for parsing and evaluating OCL constraints and expressions on the UML metamodel. (105199) [Theme: Cohesion]

EMF 2.3 / J2SE 5 Support. Adopt EMF 2.3, including regeneration of the OCL metamodel. (156361) [Theme: Design for Extensibility – Be a Better Platform]

Improved Documentation. Develop a complete Programmer’s Guide for the OCL subcomponent. (156360) [Theme: Simple to Use]

LPG. Consume LPG runtime library from the Orbit project. (156366) [Theme: Project Restructuring]

Stand-alone support. Provide a stand-alone (Eclipse-free) OCL build. (136817) [Theme: Appealing to a Broader Community]

ICU4J. Isolate and minimize dependency on ICU4J; ensure support for the “thin” variant of ICU4J. (156364) [Theme: Enable Consistent Multi-language Support]

Proposed Items (OCL component)

None at this time.

Deferred Items (OCL component)

Standard Compliance. Maintain currency of the API with the OMG’s OCL, ensuring backward API compatibility as much as possible. (156363) [Theme: Appealing to a Broader Community]

OCL Conformance. Validate and document the API’s conformance to the OCL Specification’s compliance points. This includes which language capabilities are supported and which metamodels (EMOF/Ecore, UML) are supported. (152003) [Theme: Design for Extensibility – Be a Better Platform]

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)

 Eclipse 3.3 / EMF 2.3 Compatibility. Maintain release currency concurrent with EMF 2.3 (and Eclipse 3.3). Make changes as required to align with EMF features and bug fixes, in particular support for Java SE 5.0. (160679) [Theme: Cohesion]

Improved Documentation. Improve documentation by updating the FAQ, enhancing the Javadoc, and publishing new articles. (77413) [Theme: Simple to Use]

Ant Task for Ecore Importer. Provide an Ant task for the UML Ecore importer, similar to those provided for the Rose and Ecore importers in EMF. (160680) [Theme: Design for Extensibility – Be a Better Platform]

Static Profile Definition. Provide a way to specify that a profile definition be generated using EMF. This would allow, among other things, support for custom data types and derived stereotype properties. (155535) [Theme: Appealing to a Broader Community]

XML Primitive Types. Provide a model library to represent the types defined in the XMLType metamodel in EMF; be sure to update Ecore/UML converters to make use of this new library. (150154) [Theme: Cohesion]

Create Child/Sibling Menu Reorganization. Reorganize the ‘Create Child’ and ‘Create Sibling’ menus of the UML editor so that the items are grouped by feature. (160684) [Theme: Simple to Use]

Integration with OCL. Integrate support for parsing and evaluating OCL constraints and expressions. Consider providing a convenience method on Constraint for returning the parsed representation of OCL expressions. (105199) [Theme: Cohesion]

Proposed Items (UML2 component)

None at this time.

Deferred Items (UML2 component)

Unit Tests. Complete the implementation of generated unit tests. (80308) [Theme: Design for Extensibility – Be a Better Platform]

Validation Rules. Complete the generation and implementation of validation rules from the UMLTM 2.1 source model. (80307) [Theme: Appealing to a Broader Community]

BiDi Support. Provide better support for BiDi languages. (160682) [Theme: Enable Consistent Multi-language Support]

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)

Class Diagrams. Provide a GMF-based editor for UML class diagrams. (80318) [Theme: Appealing to a Broader Community]

State Machine Diagrams. Provide a GMF-based editor for UML state machine diagrams. (161572) [Theme: Appealing to a Broader Community]

Component Diagrams. Provide a GMF-based editor for UML component diagrams. (161573) [Theme: Appealing to a Broader Community]

Activity Diagrams. Provide a GMF-based editor for UML activity diagrams. (161574) [Theme: Appealing to a Broader Community]

Proposed Items (UML2 Tools component)

None at this time.

Deferred Items (UML2 Tools component)

Import/Export from/to DI. Provide a mechanism whereby UML diagrams can be imported/exported from/to a format based on the Diagram Interchange specification. (161575) [Theme: Appealing to a Broader Community]

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)

 Java SE 5.0 Support. Exploit new Java language constructs; use generics (e.g. EList, EMap and implementations); generate and merge Java 5 constructs; investigate enumerations and annotations. (79768) [Theme: Appealing to a Broader Community]

Proposed Items (XSD component)

None at this time.

Deferred Items (XSD component)

XSD2Ecore Enhancements. Improve ability to record complex content models as Ecore annotations. (152373) [Theme: Cohesion]