Eclipse MDT
DRAFT 1.0 Plan

Last revised 21:45 EDT October 18, 2006 ( 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 "R2_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 UML2 OCL subcomponent, available as versions tagged "R1_1" in the eclipse.org CVS repository.
  • UML2 OCL runtime binary and SDK distributions (downloadable).
  • UML2 OCL runtime binary and SDK features on eclipse.org update site (install via Eclipse update manager).
  • Source code release for the UML2 Tools subcomponent, available as versions tagged "R1_0" 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 the UML2 UML subcomponent, available as versions tagged "R2_1" in the eclipse.org CVS repository.
  • UML2 UML runtime binary and SDK distributions (downloadable).
  • UML2 UML 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 "R3_0" 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, October 5 - Milestone 2 (1.0 M2) - Stable Build based on Eclipse 3.3 M2
  • Thursday, November 16 - Milestone 3 (1.0 M3) - Stable Build based on Eclipse 3.3 M3
  • Thursday, December 28 - Milestone 4 (1.0 M4) - Stable Build based on Eclipse 3.3 M4

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 3.0
  • 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 2.0 with 1.0

The EODM 2.0 component of Eclipse MDT will not be compatible with EODM 1.0.

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

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

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

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

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

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

API Contract Compatibility: XSD 3.0 will be upwards contract-compatible with XSD 2.2 except in those areas noted in the XSD 3.0 Migration Guide. Programs that use affected APIs and extension points will need to be ported to XSD 3.0 APIs. Downward contract compatibility is not supported. There is no guarantee that compliance with XSD 3.0 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 3.0 will be upwards binary-compatible with XSD 2.2 except in those areas noted in the XSD 3.0 Migration Guide. Downward plug-in compatibility is not supported: plug-ins compiled against XSD 3.0 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 3.0 APIs, although this cannot be guaranteed. Because XSD 3.0 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 3.0 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 3.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.

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. (?) [Theme: Appealing to a Broader Community]

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

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

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

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

Proposed Items (EODM component)

None at this time.

Deferred Items (EODM component)

None at this time.

UML2 component

UML2 provides an implementation of the UML 2 umbrella of standards defined by the OMG and tools to manipulate models based on those standards. Plan items reflect new features of (subcomponents of) the UML2 component, or areas where existing features will be significantly reworked ( marks completed work).

UML2 OCL subcomponent

UML2 OCL is an implementation of the OCL OMG standard for EMF-based models.

Committed Items (UML2 OCL subcomponent)

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 3.0 / J2SE 5 Support. Adopt EMF 3.0, 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]

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]

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 (UML2 OCL subcomponent)

None at this time.

Deferred Items (UML2 OCL subcomponent)

None at this time.

UML2 Tools subcomponent

UML2 Tools is set of a GMF-based editors for viewing and editing UML models.

Committed Items (UML2 Tools subcomponent)

None at this time.

Proposed Items (UML2 Tools subcomponent)

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. (80318) [Theme: Appealing to a Broader Community]

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

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

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. (?) [Theme: Appealing to a Broader Community]

Deferred Items (UML2 Tools subcomponent)

None at this time.

UML2 UML subcomponent

UML2 UML is an EMF-based implementation of the UMLTM 2.x metamodel for the Eclipse platform.

Committed Items (UML2 UML subcomponent)

Eclipse 3.3 / EMF 3.0 Compatibility. Maintain release currency concurrent with EMF 3.0 (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]

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

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 UML subcomponent)

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]

Deferred Items (UML2 UML subcomponent)

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)

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]

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

Proposed Items (XSD component)

None at this time.

Deferred Items (XSD component)

None at this time.