Modeling Project Plan

Eclipse Modeling Project Draft Plan (Europa release)

Last revised 1829 EST August 09, 2006

Please send comments about this draft plan to the modeling-pmc@eclipse.org mailing list or eclipse.modeling newsgroup.

Introduction

This document lays out the feature and API set for the first release of the Eclipse Modeling Project, to coincide with the Europa release train. This "release" of the Modeling project primarily represents a roll-up of constituent project features and API, although there are some organizational themes called out at the top-level. With that, it is expected that Modeling projects will inherit elements of this plan in order to simplify their own, as was done for the Modeling project charter as it relates to the Standard Charter.

This project plan and associated requirements are the result of an open and transparent process and includes input from those who have expressed an interest in the project. That said, the success of the project and its deliverables is soley dependent upon the contributions from its community membership. If you are interested in contributing to the project in the delivery of its stated goals, you are more than welcome!

The first part of the plan deals with the important matters of release deliverables, release milestones, target operating environments, compatibilities and dependencies. 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 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.

With the previous release as the starting point, this is the plan for how we will enhance and improve it. 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.

Release deliverables

The release deliverables have the same form as is found in most Eclipse projects, namely:

• Source code release, available as versions tagged appropriately in the project's CVS repository (e.g. "R2_0").
• SDK distribution (includes runtime and SDK components, with sources, examples, and documentation) (downloadable and update site).
• Runtime binary distribution (downloadable and update site).
• Test distribution (downloadable and update site).

Release milestones

Release milestone occurring at roughly 6 week intervals and follow the Platform milestone releases by approximately 2 weeks; that is, until the final 3.3 release of the Platform, upon which Modeling and other projects will release simultaneously. Individual projects will stagger their builds from the Platform milestone dates in order to accommodate dependencies and meet the Modeling +2 week dates. The milestones are:

• Friday August 25, 2006 - Milestone 1
• Friday Mmm XX, 200X - Milestone 2
• Friday Mmm XX, 200X - Milestone 3
• Friday Mmm XX, 200X - Milestone 4
• Friday Mmm XX, 200X - Milestone 5
• Friday Mmm XX, 200X - Milestone 6

Lock down and testing then begins with M6, and progress through a series of test-fix passes against candidates releases. Release candidate builds are planned as follows (M6 is release candidate 0):

• Friday Mmm XX, 200X - Release Candidate 1
• Friday Mmm XX, 200X - Release Candidate 2
• Friday Mmm XX, 200X - Release Candidate 3
• Friday Mmm XX, 200X - Release Candidate 4
• Friday Mmm XX, 200X - Release Candidate 5
• Friday Mmm XX, 200X - Release Candidate 6

As these milestones are dependent upon the Platform and outside dependencies, they may be altered in order to conform to the published plan. 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 Eclipse release targets reasonably current versions of the underlying operating environments.

The Eclipse Modeling Project depends upon on the Platform and other projects, which are mostly "pure" Java. The 3.3 release of the Eclipse Platform Project is written and compiled against version 1.4 of the Java Platform APIs, and targeted to run on version 1.4 of the Java Runtime Environment, Standard Edition. Modeling projects may opt to utilize Java 5 language features in their projects, as have the Eclipse Modeling Framework (EMF) and the Graphical Modeling Framework (GMF) projects.

Eclipse Platform SDK 3.3 will be tested and validated on a number of reference platforms. The Eclipse Graphical Modeling Project will be tested and validated against a subset of those listed for the platform. Those available will be presented on the project download site.

Internationalization

The Eclipse Platform is designed as the basis for internationalized products. The user interface elements provided by the Eclipse SDK components, including dialogs and error messages, are externalized. The English strings are provided as the default resource bundles. As a result, the Modeling projects will provide English strings in its default bundles and be localized to a subset of those locales offered by the Platform. This plan will be updated to indicate which locales will be provided and the timeframe for availability.

Compatibility and Dependencies

The following Modeling projects will be developed in parallel, and released simultaneously, with a number of dependent projects. As stated above, each milestone release of the Modeling projects will be compatible with the corresponding milestones for each of these projects, and delivered the appropriate offset.

• Eclipse Platform SDK version 3.3
• Eclipse Modeling Framework (EMF) version 3.0
• Eclipse Graphical Modeling Framework (GMF) version 2.0
• Model Development Tools (MDT) version 1.0
• Graphical Editing Framework (GEF) version 3.3

Therefore, the Modeling project release will include and be compatible with these versions and will publish binary and source compatibilities with migration guides on subsequent releases.

API Contract

It is a goal of the Modeling project to avoid provisional APIs. APIs published for this release will be carefully reviewed prior to release, making use of "internal" packages for unsupported and variable implementation classes. Client plug-ins that directly depend on anything other than what is specified in the published API are inherently unsupportable and receive no guarantees about future compatibility. Refer to How to Use the Eclipse API for information about how to write compliant plug-ins. Note that Modeling projects follow the posted Version Numbering guidelines.

Compatibility of Release

Modeling projects included in this release will be compatible with their previous release versions (if applicable), except in those areas noted in the applicable project Migration Guide. Individual projects are expected to specify their appropriate version compatibilities in their plan, while adhering to the guidelines listed here.

API Contract Compatibility:

This release will be upwards contract-compatible with the previous release except in those areas noted in the project's Migration Guide. Programs that use affected APIs and extension points will need to be ported to this release's APIs. Downward contract compatibility is not supported. There is no guarantee that compliance with this release's APIs would ensure compliance with the previous release's APIs. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain contract compatibility.

Binary (plug-in) Compatibility:

This release will be upwards binary-compatible with the previous release except in those areas noted in the project's Migration Guide. Downward plug-in compatibility is not supported: plug-ins compiled against this release will likely be unusable with the previous release. 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 the previous release's APIs will usually compile and run successfully against this release's APIs, although this cannot be guaranteed. Downward source compatibility is not supported. If source files use new APIs, they will not be usable with earlier versions.

Workspace Compatibility:

This release will be upwards workspace-compatible with the previous release unless noted. This means that workspaces and projects created by an Eclipse with the previous release installed can be successfully opened by an Eclipse with this release 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 APIs:

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 or Provisional API Guidelines for information about how to write compliant plug-ins.

Migration Guide

If there are issues migrating from the previous release to this release, a Migration Guide, or a secondary document will be added documenting any known issues.

Features and Capabilities

A list of project requirements and agreed upon implementation timeframes is found in this document. For the milestones listed in this document, a set of overall themes is used to indicate what major set of functionalities is to be concentrated on for each. These themes are presented below, while the requirements document and associated Bugzilla entries are left to those wanting more detailed information on each.

Themes

Taking into consideration the themes provided by the Requirements Council, and individual Modeling project requirements, the following themes are planned to be addressed in this release:

• Infrastructure Unification

For the release of multiple projects with inter-dependencies, the ability to provide a common build and reporting infrastructure will be invaluable, particularly if it is working in collaboration with Eclipse-wide [Europa_Build_Workshop | build improvements].

• Project Restructuring

With the aggregation of many projects and components in Modeling, a new logical and physical structure was devised to better organize them all. Restructuring during this release cycle to form the proposed MDT, M2M, and M2T projects and alter others will improve site navigation, component utilization, etc.

• Cohesion

The key aspect of this theme is to improve interoperability between the Modeling project components, moving toward a unified set of model-driven development capabilities for Eclipse. Additionally, there are many smallish aspects to this theme, including consistent packaging, versioning, user interface elements, etc.

Plan Items

Plan items reflect new features of each project, or areas where existing features will be significantly reworked. Plan items are indicated using keywords and have a state determined by 'Assigned To' and 'Target Milestone' fields in Bugzilla. Below is a list of possible states and what they mean:

• Committed items - A committed bug is one that we have decided to address for the release.
• Proposed items - A bug 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 items - A reasonable proposal that will not make it in to 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.

Plan Item Queries

(Aggregate individual project queries here)

Plan Items

Open | Resolved | All Items

Committed Items

Bugzillas with a target milestone and developer assigned are considered committed in that release. For the most current list of these items for the 2.0.0 release, see the following links:

Open | Resolved | All Items

Proposed Items

Bugzillas without an assigned developer are proposed, but not committed for a particular release. For the most current list of these items, see the following links:

Open | Resolved

Deferred Items

Bugzillas with an unspecified target milestone are deferred, and not scheduled for the current release. For the most current list of these items, see the following link:

All Open