Last revised
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:
The release deliverables are:
Release milestone occurring at roughly 6 week intervals exist to facilitate coarse-grained planning and staging. The milestones are:
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.
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:
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.
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.
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.
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.
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.
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.
The changes under consideration for the next release of Eclipse MDT align with themes identified by the Eclipse Requirements Council and Modeling project.
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).
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]
None at this time.
None at this time.
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).
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]
None at this time.
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 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).
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]
None at this time.
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 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).
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]
None at this time.
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 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).
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]
None at this time.
XSD2Ecore Enhancements. Improve ability to record complex content models as Ecore annotations. (152373) [Theme: Cohesion]