Eclipse MDT
DRAFT 1.0 Plan

Last revised 20:28 EST December 19, 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.

• Release deliverables
• Release milestones
• Target operating environments
• Compatibility with previous releases
• EODM component
• OCL component
• UML2 component
• UML2 Tools component
• XSD component

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 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 "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 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" Java^TM 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 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 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)

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]

Deferred Items ( OCL component)

None at this time.

UML2 component

UML2 is an EMF-based implementation of the UML^TM 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]

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 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 UML^TM 2.1 source model. (80307) [Theme: Appealing to a Broader Community]

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)

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)

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]

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)

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.

Mylar

Milestones

Mylar milestones are released 1 week after Eclipse milestones. Click to view open bugs.

• 2.0M1: February 16, 2007
• 2.0M2: March 30, 2007
• 2.0M3: May 11, 2007
• 2.0RC1: June 15, 2007
• 2.0: June 29, 2007

Scope

The first goal of Mylar is to make task and context management seamlessly integrated with the Eclipse Platform by providing rich and extensible frameworks for task repository connectors, structure bridges and team support. The second goal is to provide a reference implementation of the Task-Focused UI for the Eclipse SDK. This includes structure bridges for the artifacts supported by the SDK which include Java, PDE, Ant and generic files. It also includes the Bugzilla Connector as the reference task repository implementation, and CVS integration as the reference team support. Additional features can be considered based on the availability community contributions and resources.

Priorities

In addition to using the planned themes listed below, we need to continue prioritizing the ongoing input of our growing user community. Committers should prioritize bugs in the following order. This order need not be used if a bug contains a community contribution of a patch, in which case the quality of the patch determines the priority.

1. Frameworks & APIs: Tasks Framework, Context Framework, Monitor Framework, headless use
2. UI: Tasks List, Task Editor, Task-focused UI
3. Connectors: Bugzilla (reference implementation), Trac (committer supported), JIRA (community supported)

Platforms

• Eclipse 3.3: supported
• Eclipse 3.2: supported, post 2.0 maintenance builds only
• Requires Java 5 and later

Themes

Legend: in progress, completed, optional

Task List

• Support date view in Task List. A common way of organizing tasks to work on in the current week is by day. We should support this by integrating the Task Activity view's date range container presentation with the Task List. (147084)

• Support integration with planning and calendaring tools. Many task repositories have facilities for task planning in the form of milestones, due dates, and other organizations of tasks. The Task List and Task Editor should support such extensions, for example, allowing the Task List to be organized by milestone. (Calendaring, privacy controls) (e.g. 152490).

• Support task dependencies. Many tasks are related to other tasks, whether it's because they should be worked on in sequence or are subtasks. We should make these dependencies explicit in the Task List and Task Editor. (137543)

• Support working set groupings. A Task List that includes projects from multiple "working spheres" (e.g. Project A, Project B, Personal) can become unwieldy and distracting. Integration of top-level working sets could address this.

Task Editing

• Increase Task Editor information density. The task editor is a very frequent target of interaction, and we need to continue streamlining it. When opened it should show the user the most relevant information with minimal clicking and scrolling required. (158921).

• Improve task activity timing. We currently have a task activity mechanism, but it is not explicit enough, and does not capture time spent outside of the workbench. It should also be extensible to OS-specific monitoring. (135668).

• Provide task workflow mechanism. There are many common workflows, such as commit/complete/deactivate. We should provide a mechanism for specifying and executing task-related workflows. This requires direct editing of task data (i.e., without editor submission). (160780, 124224)

• Streamline task creation. Make it easier to create tasks, fork them, or promote local tasks to repository tasks. (154896, 152211)

Task Repositories

• Make offline cache faster and more robust. The offline cache is currently one large serialized file. We should make it more robust so that changes to connectors and the framework do not cause the offline data to be cleared. This should make it possible to put a repository into offline mode permanently, and never lose the task data. (165809)

• Streamline task searching. It is currently impossible to search through local and cached task data. We could improve the search experience by providing Google-style syntax in the Task List find box, e.g. severity=critical. (bug 163341)

• Improve connectivity problem and performance handling. Lack of or degraded connectivity should be transparent, and jobs should be cancellable. (165833)

• Improve synchronization control. (offline mode for repositories bug 165809, finer-grained control bug 165473)

• Provide standard XML for for tasks. We should create a canonical and extensible XML for for tasks that we use for retrieving task data. Connector providers returning this form would not need custom attribute mappings.

• Improve consistency between local and repository tasks. Need to consider how to promote task between local and repository, and whether local tasks should be a kind of repository. (12431)

Task-Focused UI

• Provide preview and editing of task context. For submitting and retrieving contexts, or wanting to inspect a context for a non-active task, we should provide a preview pane. This should also support operations such as merge and element deletion. (bug 107259)

• Support debugging views. This includes improved filtering of the thread tree, and automatic toggling/loading of breakpoints with task context.

• Preserve element identity through refactoring. Currently only the active context participates in refactoring. We either need to maintain a dependency map to update the element handles of inactive contexts, or migrate them when they are activated, via the refactoring history. (164243)

General

• Improve error handling and resolution. When an error happens, we should do automatic duplicate detection, and if no duplicate is found prompt to submit a bug to the failing plug-in.

• Generalize task and context storage mechanisms. Our API currently specifies files and paths as the storage mechanism, but it should be general, to allow for alternate mechanisms such as server-based storage.

• Improve representation of people. Support real names, selecting CCs, content assist for fields with people. The user's identity should be represented in the UI (e.g. different icon when user appears in the CC list).

• Hyperlinking everywhere. Wherever structured elements show up, we should be hyperlinking them (e.g. bug 165827)

• Personal monitoring and usage sharing. We require data from the Mylar monitor to inform our UI design. We should also make this data available to others, since it will include general Eclipse usage statistics. In order to provide users with an incentive to share their (anonymous) usage data we should include personal interaction monitoring facilities.

Platform

The Eclipse Project DRAFT 3.3 Plan

    Please send comments about this draft plan to the eclipse-dev@eclipse.org developer mailing list.

This document lays out the feature and API set for the next feature release of the Eclipse SDK after 3.2, designated release 3.3.

• Release deliverables
• Release milestones
• Target operating environments
• Compatibility with previous releases
• Eclipse Platform project
• Java development tools (JDT) project
• Plug-in development environment (PDE) project
• Equinox project

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, we (the Eclipse Project PMC) post plans in an embryonic form and revise them 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 all of the sub-projects under the top level Eclipse Project. Each plan item covers a feature or API that is to be added to the Eclipse Project deliverables, or some aspect of the Eclipse Project 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 component; others may involve coordinated changes to several components; other may pervade the entire SDK. Although some plan items are for work that is more pressing than 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.

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 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.

Release deliverables

The release deliverables have the same form as previous releases, namely:

• Source code release for all Eclipse Project deliverables, available as versions tagged "R3_3" in the Eclipse Project CVS repository.
• Eclipse SDK (runtime binary and SDK for Equinox, Platform, JDT, and PDE) (downloadable).
• Eclipse Platform (runtime binary and SDK for the Equinox and Platform only) (downloadable).
• Eclipse RCP (runtime binary and SDK for the Rich Client Platform) (downloadable).
• Eclipse JDT (runtime binary and SDK for the Java Development Tools) (downloadable).
• Eclipse PDE (runtime binary and SDK for the Plug-in Development Environment) (downloadable).
• Eclipse SDK Examples (downloadable).
• SWT distribution (downloadable).
• Equinox OSGi R4 framework and assorted service implementations (downloadable).

Release milestones

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

• Thursday Aug. 10, 2006 - Milestone 1 (3.3 M1) - stable build
• Friday Sep. 22, 2006 - Milestone 2 (3.3 M2) - stable build
• Friday Nov. 3, 2006 - Milestone 3 (3.3 M3) - stable build
• Friday Dec. 15, 2006 - Milestone 4 (3.3 M4) - stable build

Our target is to complete 3.3 in 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 Eclipse release targets reasonably current operating environments.

Most of the Eclipse SDK is "pure" Java code and has no direct dependence on the underlying operating system. The chief dependence is therefore on the Java Platform itself. Portions of the Eclipse SDK (including the RCP base, SWT, OSGi and JDT core plug-ins) are targeted to specific classes of operating environments, requiring their source code to only reference facilities available in particular class libraries (e.g. J2ME Foundation 1.0, J2SE 1.3 and 1.4, etc.). With the exception of a small set of planned features that actually require Java SE 5 APIs (most notably, the support for Annotation Processing and JUnit 4), the 3.3 release of the Eclipse Project is developed against version 1.4 of the Java 2 Platform. As such, the Eclipse Project SDK as a whole is targeted at both 1.4 and Java5 VMs, with full functionality available for 1.4 level development everywhere, and new Java5 specific capabilities available when running on a Java5 VM. Appendix 1 contains a table that indicates the class library level required for each plug-in.

There are many different implementations of the Java Platform running atop a variety of operating systems. We focus Eclipse SDK testing on a handful of popular combinations of operating system and Java 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 a 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.

The Eclipse SDK 3.3 is tested and validated on the following reference platforms (this list is updated over the course of the release cycle):

Eclipse Reference Platforms
Operating system	OS version	Processor architecture	Window system	Java 2 Platform
Microsoft Windows	XP	Intel x86	Win32	Sun Java 2 Standard Edition 5.0 Update 6 for Microsoft Windows
Microsoft Windows	XP	Intel x86	Win32	IBM 32-bit SDK for Windows, Java 2 Technology Edition 5.0
Microsoft Windows	XP	Intel x86	Win32	BEA JRockit 5.0, for Microsoft Windows
Microsoft Windows	XP	Intel x86	Win32	Sun Java 2 Standard Edition 1.4.2_10 for Microsoft Windows
Microsoft Windows	XP	Intel x86	Win32	IBM 32-bit SDK for Windows, Java 2 Technology Edition 1.4.2 service release 3
Microsoft Windows	XP	Intel x86	Win32	BEA JRockit 1.4.2, for Microsoft Windows
Red Hat Enterprise Linux	WS 4	Intel x86	GTK	Sun Java 2 Standard Edition 5.0 Update 6 for Linux x86
Red Hat Enterprise Linux	WS 4	Intel x86	GTK	IBM 32-bit SDK for Linux on Intel architecture, Java 2 Technology Edition 5.0
Red Hat Enterprise Linux	WS 4	Intel x86	GTK	BEA JRockit 5.0, for Linux x86
Red Hat Enterprise Linux	WS 4	Intel x86	GTK	Sun Java 2 Standard Edition 1.4.2_10 for Linux x86
Red Hat Enterprise Linux	WS 4	Intel x86	GTK	IBM 32-bit SDK for Linux on Intel architecture, Java 2 Technology Edition 1.4.2 service release 3
Red Hat Enterprise Linux	WS 4	Intel x86	GTK	BEA JRockit 1.4.2, for Linux x86
SUSE Linux Enterprise Server	9	Intel x86	GTK	Sun Java 2 Standard Edition 1.4.2_10 for Linux x86
SUSE Linux Enterprise Server	9	Intel x86	GTK	IBM 32-bit SDK for Linux on Intel architecture, Java 2 Technology Edition 1.4.2 service release 3
Sun Solaris	10	SPARC	GTK	Sun Java 2 Standard Edition 1.4.2_10 for Solaris SPARC
HP HP-UX	11i	hp9000 PA-RISC	Motif	HP-UX JDK for the Java 2 Platform Standard Edition for 1.4.2_09
IBM AIX 5L	5.2	Power	Motif	IBM 32-bit SDK for AIX, Java 2 Technology Edition 1.4.2 service release 3
Apple Mac OS X	10.4	Power	Carbon	Java 2 Platform Standard Edition (J2SE) 1.4.2 service release 2 for Tiger
Red Hat Enterprise Linux	WS 4	Power	GTK	IBM 32-bit SDK for Linux on pSeries architecture, Java 2 Technology Edition 1.4.2 service release 3
SUSE Linux Enterprise Server	9	Power	GTK	IBM 32-bit SDK for Linux on pSeries architecture, Java 2 Technology Edition 1.4.2 service release 3
SUSE Linux Enterprise Server	9	Power	GTK	IBM 32-bit SDK for Linux on pSeries architecture, Java 2 Technology Edition 1.4.2 service release 3

Because Java 1.4.2 platforms are used for most Eclipse development, in general, 1.4.2 platforms are listed here. Of course, the teams doing Java 5 based development are using Java 5 platforms, and the specific ones that they test on are also included. We expect that Eclipse will work fine on other Java 5 VMs running on window systems supported by SWT, but can not flag these as reference platforms without significant community support for testing them.

Similarly, although untested, the Eclipse SDK should work fine on other OSes that support the same window system. For Win32: Windows 98, ME, NT, 2000, and Server 2003; SWT HTML viewer requires Internet Explorer 5 (or higher). For GTK on other Linux systems: version 2.2.1 of the GTK+ widget toolkit and associated libraries (GLib, Pango); SWT HTML viewer requires Mozilla 1.4GTK2. For Motif on Linux systems: Open Motif 2.1 (included); SWT HTML viewer requires Mozilla 1.4GTK2.

An early access version of the Eclipse SDK is also available for 64-bit Linux GTK. Testing has been limited to early access 64-bit J2SEs running on x86-64 processors.

SWT is also supported on the QNX Neutrino operating system, x86 processor, Photon window system, and IBM J9 VM version 2.0. Eclipse 3.3 on Windows or Linux can be used to cross-develop QNX applications. (Eclipse 3.3 is unavailable on QNX because there is currently no 1.5 J2SE for QNX.)

Internationalization

The Eclipse SDK 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.

Latin-1 locales are supported by the Eclipse SDK on all of the above operating environments; DBCS locales are supported by the Eclipse SDK on the Windows, GTK, and Motif window systems; BIDI locales are supported by the Eclipse SDK only on Windows operating environments.

The Eclipse SDK supports GB 18030 (level 1), the Chinese code page standard, on Windows XP and 2000, and Linux/GTK.

German and Japanese locales are tested.

BIDI support

SWT fully supports BIDI on Windows. On Linux GTK, SWT supports entering and displaying BIDI text. Within these limitations, the Eclipse SDK tools are BIDI enabled.

Compatibility with Previous Releases

Compatibility of Release 3.3 with 3.2

Eclipse 3.3 will be compatible with Eclipse 3.2 (and, hence, with 3.1 and 3.0).

API Contract Compatibility: Eclipse SDK 3.3 will be upwards contract-compatible with Eclipse SDK 3.2 except in those areas noted in the Eclipse 3.3 Plug-in Migration Guide . Programs that use affected APIs and extension points will need to be ported to Eclipse SDK 3.3 APIs. Downward contract compatibility is not supported. There is no guarantee that compliance with Eclipse SDK 3.3 APIs would ensure compliance with Eclipse SDK 3.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: Eclipse SDK 3.3 will be upwards binary-compatible with Eclipse SDK 3.2 except in those areas noted in the Eclipse 3.3 Plug-in Migration Guide . Downward plug-in compatibility is not supported. Plug-ins for Eclipse SDK 3.3 will not be usable in Eclipse SDK 3.2. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.

Source Compatibility: Eclipse SDK 3.3 will be upwards source-compatible with Eclipse SDK 3.2 except in the areas noted in the Eclipse 3.3 Plug-in Migration Guide . This means that source files written to use Eclipse SDK 3.2 APIs might successfully compile and run against Eclipse SDK 3.3 APIs, although this is not guaranteed. Downward source compatibility is not supported. If source files use new Eclipse SDK APIs, they will not be usable with an earlier version of the Eclipse SDK.

Workspace Compatibility: Eclipse SDK 3.3 will be upwards workspace-compatible with Eclipse SDK 3.2 unless noted. This means that workspaces and projects created with Eclipse SDK 3.2, 3.1 or 3.0 can be successfully opened by Eclipse SDK 3.3 and upgraded to a 3.3 workspace. This includes both hidden metadata, which is localized to a particular workspace, as well as metadata files found within a workspace project (e.g., the .project file), which may propagate between workspaces via file copying or team repositories. Individual plug-ins developed for Eclipse SDK 3.3 should provide similar upwards compatibility for their hidden and visible workspace metadata created by earlier versions; 3.3 plug-in developers are responsible for ensuring that their plug-ins recognize 3.2, 3.1, 3.0, 2.1, and 2.0 metadata and process it appropriately. User interface session state may be discarded when a workspace is upgraded. Downward workspace compatibility is not supported. A workspace created (or opened) by a product based on Eclipse 3.3 will be unusable with a product based an earlier version of Eclipse. Visible metadata files created (or overwritten) by Eclipse 3.3 will generally be unusable with earlier versions of Eclipse.

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 Eclipse SDK API are inherently unsupportable and receive no guarantees about compatibility within a single release much less with earlier releases. Refer to How to Use the Eclipse API for information about how to write compliant plug-ins.

Themes and Priorities

The PMC of the Eclipse Project has identified six major areas of work, that will be the priorities for this development cycle. These areas will address the major themes identified by the Eclipse Requirements Council (Themes and Priorities v2.0).

Although there are four projects under the top-level Eclipse Project, there is a significant amount of commonality and shared effort between them. In general, many plan items involve coordinated changes to multiple components, and thus attempting to separate the items into sections based on sub-project leads to artificial distinctions between them (e.g. Platform Text vs. JDT Text, Platform Debug vs. JDT Debug, etc.).

In order to provide the clearest focus for our development effort, we have organized the items below into sections based on the work area they are intended to address. Items that apply to multiple work areas are categorized based on where the most effort is expected to occur. In all cases, the items listed reflect new features of Eclipse or areas where existing features will be significantly reworked. Numbers in parentheses link to bugzilla problem reports where progress on that item can be tracked and discussed.

The major work areas are:

• Components
• Consumability
• Java
• Vista
• UI Evolution
• API

Components

This work will enhance Eclipse's use of, and support for, software components, covering everything from component programming models such as Declarative Services, API tools, incremental building and fine-grained function delivery.

Committed Items (Components)

None at this time.

Proposed Items (Components)

( new) Improved support for provisioning. Eclipse has advanced quite quickly with new use-cases (RCP, Equinox, server side, etc.) and new technologies (e.g., OSGi and OSGi's MEG) coming into the picture. To date Update Manager has not been enhanced to support or exploit these changes. In 3.3 we will investigate provisioning support for enhanced workflows, the ability to update the so-called "root files" (e.g., startup.jar, eclipse.exe), improved efficiency (download and disk footprint), support for right-grained discovery and acquisition of function as well as integration with differing repository types. This effort also includes enhancements to the tooling around provisioning. [Update] (154077)

( new) API tools. More components means more API and an elevated need for solid APIs, evolved but compatible APIs and the correct and understood use of APIs. This cannot be achieved without supporting tooling. Today PDE includes sophisticated support for classpath management and access rule management based on information in the manifest of bundles to facilitate the capture of package and class references. In 3.3. we will expand this to cover finer-grained API contracts (e.g., clients should not call foo() or extend Bar). Similarly, developers will be given effective mechanisms for discovering, visualizing and minimizing dependencies in their code, bundles produced by third parties and non-bundled code libraries. Tooling in support of checking and managing the evolution of component and package version numbers will also be supplied. [PDE] (154078)

( new) Bundle/Module Development Tools. In 3.1 and 3.2 PDE made gigantic strides in support for traditional OSGi bundle development. Even still, in 3.3. we will improve various workflows and classpath management strategies to promote the development of robust and independent right-grained components. This covers everything from increased quick-fix and manifest editing support to deeper integration with JDT (e.g., support for searching JARs that are not in the workspace without implicitly importing the JARs). In addition, as JSR 291 evolves in the Java SE 6 time frame, PDE will be there to provide developer support. 3.3 will include tooling around OSGi Declarative Services and the new application model as well as improved support for launching other frameworks, Java applications with bundle based classpaths and "hot launching" frameworks. [PDE] (154079)

( new) Target Provisioning. Currently, users wanting additional function supplied by others must manually acquire and install these additional bundles in their target platform. This process is tiresome and error-prone. As an extension to the proposed provisioning work, we will add the ability to provision targets directly from bundle repositories as well as from other locations on the local machine. As part of this the mechanism by which source is packaged, acquired and looked up will be reviewed and streamlined. [Update] (154081)

( new) Bundle Management. Managing even modest systems of bundles can be complex and error prone. There are several places in PDE where developers need to list or select sets of bundles (e.g., launch configurations, target setup, etc). In many cases the environment already includes relevant grouping constructs (e.g., features, working sets, bundle groups). PDE should surface these to developers in a clear, consistent and pervasive fashion. [PDE] (154082)

( new) Incremental Plug-in Build. With the increase in plug-ins coming from and going to third parties the development cycle needs to be more incremental. In the Eclipse project itself we have started to consume pre-built plugins such as ICU4J and SSH2. This trend is likely to continue as, for example, Apache seeks to deliver their libraries as bundles and more people look to consume individual bundles/components from Equinox and similar projects. As such, the build process should support the incremental building of plug-ins (that is building plugins individually) based on a set of pre-built plugins kept in some sort of provisioning repository. Plug-ins coming out of the build should feed into said repository to be used as a base for future builds. This ability will in turn enable the more frequent building of whole systems (since you build only what has changed) and simplify incremental, milestone and release build cycles. [PDE Build] (154083)

( new) Application Model. The OSGi R4 MEG specification includes an application model that significantly decouples the application from the rest of the system. The net result is OSGi (and thus Eclipse) as a more flexible application container, for example allowing multiple applications to run concurrently and improved lifecycle around the application. These characteristics are important both to the manageability of the system (e.g., simplifying and clarifying the shutdown process) but also to various RCP scenarios such as Kiosk-mode and Application Container models. In 3.3 we will implement and adopt the MEG application model. [Equinox] (154084)

( new) OSGi R5 Specification Work. Much of the success Eclipse has enjoyed with OSGi comes from the fact that the Eclipse community has played a very active role in the evolution of various OSGi specifications. With increased interest in OSGi and Java modularity (see JSR 277, JSR 291 and JSR 232) this participation has never been more important. In addition to promoting Eclipse use-cases and the evolution of these standards to benefit Eclipse, there are a number of gaps in the OSGi specifications that Eclipse is currently filling in specific ways and should be addressed in R5. For example the management of API in metadata (x-friends and x-internal), integration techniques for third party and legacy code, in-place execution of bundles, basic notions of data location, etc. The Equinox team will continue their active participation in these specification processes and keep Eclipse on the leading edge of Java componentization. [Equinox] (154085)

( new) Server side support. First it was tools, then it was applications, now server-side programmers are waking up to the power of componentization delivered by Eclipse and OSGi. In the 3.2 cycle an Equinox incubator was started to investigate the use of Eclipse on the server. It started as a very modest servlet bridge allowing Eclipse to run inside a servlet engine and handle servlet requests and has been evolving into a full-blown appreciation of what it means to componentize server software. There are many possible directions here and there is no way the Equinox team proper will be able to track, support and participate in all. However we will spend time understanding the basic requirements as they apply to the base framework and add-on services and look to support the use-cases presented by various other Eclipse projects that are adopting Eclipse on the server (e.g., ECF, ECP, Corona). [Equinox] (154087)

Defered Items (Components)

None at this time.

(End of items for Components.)

Consumability

This work will make it easier for users to get Eclipse, install it on their systems, and configure it for their use. It will also enhance the error handling and reporting mechanisms to make it easier to service Eclipse in the field. Finally, it will improve the scalability and performance of Eclipse, to provide a better experience for users working with many plug-ins and large data sets.

Committed Items (Consumability)

None at this time.

Proposed Items (Consumability)

( new) Improve the launching experience. We will look for ways to improve the current launching experience. This may include efforts such as using SWT to build the splash screen, improving the look and utility of the workspace launcher, supporting "fast switching" between workspaces, and simplifying the experience for first-time users. [SWT, Runtime, Workspace, UI, UA] (154088)

( new) Improve serviceability. When an end user encounters a problem with Eclipse, it is important for support teams to be able to diagnose the root cause of the failure, and identify the failing plug-in. Eclipse should have enhanced error reporting tools that make it easy for end users to report problems. Tools should be available at all times, so that knowledgeable users can diagnose unexpected behavior such as slow-downs or exceptional memory use. Error handling is done in a variety of ways within the platform which are not extensible to RCP applications. An improved story would allow for the inclusion of application defined error support (such as a link to a support centre for the product) and remote monitoring/inspection of system health and would tie the current error reporting story together into a solution with a more consistent look and fewer error reporting paths for developers. [Runtime, UI] (154090)

( new) Managing and sharing settings. Currently settings are either scoped at the workbench/workspace level or the project level. However, there are cases where associating settings with other scopes, such as a working set or perspective, would be beneficial. Similarly, a product should be able to specify the default settings for a particular perspective. We will also look for ways to simplify how we share settings and other interesting state, such as breakpoints, bookmarks, perspectives, key bindings, etc. [Runtime, Workspace, UI] (154097)

( new) Customization. Eclipse lacks customization capabilities aimed at end users and product packagers. More generally, component development and use is fraught with producer/consumer problems. Component producers implement solutions that address a number of use-cases and scenarios but inevitably consumers come up with additional, sometimes quite divergent requirements. We will investigate mechanisms and facilities that allow component consumers to "override" or replace metadata specifications in the components they are consuming. Such mechanisms would, for example, allow consumers to configure menus, tool bars, and perspectives of their Eclipse installation as well as refine plug-in dependency declarations. [Runtime, UI] (154099)

( new) Platform level proxy settings. There are at least three proxy settings pages in Callisto. We will work with the Eclipse community to make sure that the core capabilities from these pages are made available at the Platform level, as a single settings page that can be consumed by all. [Runtime, Team, Update, UI] (154100)

( new) GTK Printing. We will provide printing support on GTK. [SWT] (154101)

( new) Ship Finer-grained Components. The Eclipse project produces three major outputs, the Platform, JDT and PDE. These are exposed as zips on download sites and features on update sites. Those wanting to get just part of one of these components (e.g., Help, Update, JDT Core) must first discover which zip or feature contains the desired function, acquire that container and finally identify and extract the desired plug-ins. To make this easier we will revise the grouping structure to capture more independent and re-usable components. [All components] (154102)

( new) Search based navigation. Because traditional navigation-by-browsing does not scale to large data sets, we should generalize and extend the existing search-based rapid navigation mechanisms (e.g. "Quick Find Class"). [UI, UA] (154104)

( new) Performance focus. We must continue to improve overall performance and memory consumption, with a particular focus on working with large numbers of plug-ins and large amounts of data. [All components] (154106)

Defered Items (Consumability)

None at this time.

(End of items for Consumability.)

Java

The Eclipse Java Development Tools are the premier Java development environment in the industry today. We must address the new capabilities of Java SE 6 and continue to refine and extend the features JDT provides to maintain its leadership position.

Committed Items (Java)

None at this time.

Proposed Items (Java)

( new) Enhance launching support. We should simplify the launch experience for novice users with single click context sensitive launching, simple launch configurations managed via resource properties, and user configurable toolbar buttons to invoke favorite launch configurations. For advanced users, we should allow plug-ins to contribute additional pages to launch configurations so that plug-in specific information (such as profiling and code coverage settings) can be associated with each configuration. [Debug] (154107)

( new) More refactorings. We will finish the 'Fix Deprecation' refactoring that didn't make it into 3.2, and add the new refactoring 'Replace Invocation'. More refactoring API will be offered in the plug-in org.eclipse.jdt.core.manipulation so the refactoring infrastructure can be used with a UI. [JDT UI] (154108)

( new) Extend Clean Up. Add formatting, organize import and sort members to 'Clean up', offer clean up profiles, and invoke clean up on user defined events. [JDT UI] (154109)

( new) Enhance Annotation Processing Tooling. An APT command-line tool should be provided as a complement to the batch compiler and/or Ant javac adapter, in addition to the Java IDE support within release 3.2. APT should also support the new standard Annotation Processing API (JSR 269) introduced in Java SE 6, as opposed to the provisional API from Sun introduced in Java SE 5 that is currently implemented. Also, the APT integration in IDE should be improved in various areas, including editor reconciling and code assist. The editor reconciling experience should work correctly even if the Java builder is not active. Currently, if a processor generates types, those types are ignored during reconcile. Instead, they should be modeled using working copies, and provide the same level of functionality as JDT when autobuild is turned off. Also, on the code-assist front, we should provide a simple API for processors to supply domain specific knowledge to completions inside annotation values. [JDT APT] (154110)

( new) Compiler API (JSR 199). In order to conform to the forthcoming tool API for compilers (JSR 199), the Eclipse compiler should provide a front-end implementing the tool API included in Java SE 6. [JDT Core] (154111)

( new) Add more class file targets for compiler. The compiler should support more configurable class file targets, including CLDC 1.0, CLDC 1.1 and possibly JSR 14 (generics experimentation for 1.4 VMs). [JDT Core] (154113)

( new) Support for Java SE 6 debug features. Implement new Java SE 6 features in the Eclipse Java Debug Interface (JDI) client including support for heap walking (retrieve instance counts, all intances of specific types, and all references to an object), forcing an early return from a method with a specific return value, breakpoints for monitor acquisition and release, access to the constant pool, and improved class prepare event filtering. [JDT Debug] (154115)

Defered Items (Java)

None at this time.

(End of items for Java.)

Vista

Microsoft Vista is a significant new desktop platform that we expect will become available during this development cycle. We should fully support running the current, win32-based version of Eclipse on Vista. We should also port SWT to WinFX and the Windows Presentation Framework.

Committed Items (Vista)

None at this time.

Proposed Items (Vista)

( new) Fully support the win32 version of SWT on Vista. We should ensure that applications built on the win32 version of SWT work as well as any other win32 API based application on Vista. This will increase our testing and support effort and potentially require new development to work around platform specific differences. [SWT] (154116)

( new) Port SWT to WinFX and WPF. We should port SWT to WinFX and the Windows Presentation Framework. Since 64-bit systems are becoming increasingly prevalent on the desktop, we should ensure that this port is both 64-bit and 32-bit capable. [SWT] (154117)

( new) Generalize the win32 version of SWT to win64. We should merge the work being done by the Eclipse community to implement a win64 implementation of SWT into the main win32 code base. This will require extensive review of the new code and a significant effort to merge and test the pervasive changes. [SWT] (154118)

Defered Items (Vista)

None at this time.

(End of items for Vista.)

UI Evolution

The goal of this work is to provide a better basis for building modern, rich user-interfaces, by addressing areas where more flexibility and more consistency are needed. We will use these capabilities to refine the user-interface of the Eclipse IDE. In addition, we will implement of the most requested missing IDE productivity features.

Committed Items (UI Evolution)

None at this time.

Proposed Items (UI Evolution)

( new) Implement missing text editor productivity features. We should provide some of the long awaited productivity features that the community has voted for. Examples include double-click-drag to select multiple words, triple-click, extensible hyperlink support and spell checking. We should also improve the current search/replace dialog. [Platform Text, Platform UI, SWT] (154119)

( new) Improve workbench usability. We should review how users interact with the workbench, such as how editors, views, and other screen real-estate are managed (e.g. fix the broken minimize), and find ways to make this a better experience for them. This includes improving the new trim support by allowing the end user to hide/show, close and otherwise configure trim items, improving navigation from hovers (e.g. quick diff), making fast views more flexible (fast views on all sides, fast view orientation affinity, fast view bars show text option). [Platform UI, Platform Text, JDT UI, JDT Text] (154120)

( new) Improve multi-instance view management. Views such as Search and Synchronize use a drop-down menu to manage multiple pages. Another possibility would be to use multiple view instances. However, the presentation and management of these two approaches are different. Multiple view instances should support different view presentations. That is, the user (or product) should be able to decide whether multiple views use tabs or a drop-down menu. There are also shortcomings in multi-view management (e.g., views are managed at the perspective level but some tooling may require the ability to close a particular view in all perspectives). [UI] (154121)

( new) Investigate background saving of editors. Modern applications allow editing sessions to be saved in the background, allowing the user to continue editing or close the editor without waiting. We should investigate whether this style of interaction can be built on top of the Eclipse editor framework. [Platform Text, JDT Text, Platform UI] (154122)

( new) JFace Enhancements. Ensure that the reusable components in JFace fully support the SWT widget set, such as support for the new custom draw capabilities of the Table and Tree widgets. Also, implement some of the components that we do not use in the SDK currently that the community is requesting. Some examples include: spinners, secure editors (such as password entry fields) fields that enforce a format (such as fields for currency and percentages), etc. [Platform UI, SWT] (154123)

( new) Mozilla Everywhere. For situations where the existing, platform-browser-based Browser control is not sufficient, we should support embedding of Mozilla on all platforms. This would allow developers to implement code that worked against a common back end, so that they could access a common DOM, or surface the browser's HTML editing support. [SWT] (154124)

Defered Items (UI Evolution)

None at this time.

(End of items for UI Evolution.)

API

This work area deals specifically with issues concerning the application programming interfaces provided by the Eclipse Project. We will identify API whose function has been superceded, and ensure that the SDK does not depend on this API. We will encourage adoption within the SDK of some of the more recent additions to Eclipse, such as the command framework, Equinox preferences, tabbed properties and the common navigator. We will work with the community to ensure that needed functionality is made available as API, when it reaches appropriate levels of maturity.

Committed Items (API)

None at this time.

Proposed Items (API)

( new) Generalize editor annotation and ruler support. We should allow plug-ins to contribute additional vertical rulers to show additional information (e.g. code coverage). We should support live annotate "color by age" in addition to "color by contributor". [Platform Text] (154125)

( new) Adopt the Eclipse File System. We should ensure that use of the Eclipse File System is pervasive in the platform, and remove any barriers that prevent it from being more widely adopted by the community. For example, we should provide IFileStoreEditorInput and a matching default implementation. [Workspace, UI, Platform Text] (154126)

( new) Adopt the new UI features. We should adopt the following items across the entire SDK UI: the new command framework, preference initializers, field assist, SWT column sort indicators, working sets, tabbed properties view and the common navigator. [UI, JDT UI, PDE, Team, Text] (154127)

( new) Provide access to more native controls. We should provide access to more of the native controls that are available on each platform, such as date and time pickers, and table header widgets. In addition, we should enable more features of existing native controls, such as table wrapping on Windows. [SWT, UI] (154128)

( new) Custom widget API support. Investigate ways to simplify the process of writing custom widgets, including making available, as API, some of the currently internal capabilities of the custom widgets implemented in the SDK, such as drag under feedback for drag & drop. [SWT] (154129)

( new) Finish re-work of commands and key bindings. In 3.2, we built some important infrastructure that will allows us to rationalize our commands and key bindings story. We need to complete this effort, making sure the new story supports all of the existing functionality (e.g action sets), and migrate over to the new support. We also need to make it easier to add and edit key bindings. [UI] (154130)

( new) JFace data binding. In 3.2, we developed a data binding framework for JFace but did not make it generally available. We should continue to work towards providing a public API for this framework and investigate how it will be delivered and used within the SDK. [UI] (154132)

( new) Improve compare. The Compare plugin has not undergone much work in the last few releases and is showing it. From an architectural standpoint, there are several Compare internals that need to be made API in order to properly support clients and there are also several polish items that have been identified by Eclipse development teams. In addition, new ISaveable support was added in 3.2 and we should investigate integrating this into Compare. From a usability standpoint, the compare editor uses a custom viewer for content which appears similar to the related editor but has a reduced capability which is often confusing for users. Smaller usability issues involve breaking out the outline from the editor into the Outline view. There is supported by compare but is not used by Team or other Platform clients. [Team] (154133)

( new) Graphics Improvements. The SWT graphics layer should provide support for fractional line widths, dashes and fonts, the ability to flatten paths, image loading/saving improvements, and other similar enhancements. [SWT] (154134)

( new) APIs for custom debugger integration. Publish public APIs based on the provisional APIs introduced in 3.2 to support custom debugger integration. Features include flexible hierarchy in debug views; asynchronous, cancellable interactions when retrieving content and labels; model-driven view updates; a debug context service for retargettable actions, flexible view wiring and pluggable source lookup. [Platform Debug] (154135)

Defered Items (API)

None at this time.

(End of items for API.)

Appendix 1: Execution Environment by Plug-in

In the table below, the "3.3 EE" ("3.3 Execution Environment") column indicates the minimum Java class library requirements of each plug-in for the 3.3 release, where the value is one of:

Test and Performance Tools Platform (TPTP)

Eclipse Test & Performance Tools Platform (TPTP) Project
4.3 Plan (Approved)

Last revised 10/23/2006 09:23 PM Pacific Time ( marks interesting changes since September 2006)

    Please send comments about this plan to the tptp-pmc@eclipse.org PMC mailing list.

This document lays out the feature and API set for the TPTP 4.3 release.

• Release Deliverables
• Release Milestones
• Target Operating Environments
• Compatibility with Previous Releases
• Themes
• Projects
• Features
• Defects

The first part of this 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 four projects under the TPTP Top-Level Project.  Each plan item covers a feature or API that is to be added to TPTP, or some aspect of TPTP that is to be improved.  Each plan item has its own entry in the TPTP 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 component; others may involve coordinated changes to several components; other may pervade the entire project.

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 following release deliverables are provided:

• Runtime
• Source
• Examples
• Component Test
• Data Collection Engine for Windows (NT, 2000, XP) x86 Runtime
• Data Collection Engine for Windows (XP, Server 2003) x86/64-bit Runtime
• Data Collection Engine for Windows Server 2003 Itanium Runtime
• Data Collection Engine for Linux x86 Runtime
• Data Collection Engine for Linux x86/64-bit Runtime
• Data Collection Engine for Linux Itanium Runtime
• Data Collection Engine for Linux zSeries Runtime
• Data Collection Engine for zSeries Runtime
• Data Collection Engine for iSeries Runtime
• Data Collection Engine for Solaris Sparc Runtime
• Data Collection Engine for AIX PPC Runtime
• Data Collection Engine for Linux PPC/64-bit
• Data Collection Engine for HP-UX Runtime
• Native Logging Implementation (All platforms)
• Plugin Translatability Log

Release Milestones

The TPTP 4.3 release is targeted for general availability on 27-Oct-2006.  All release deliverables will be available for download as soon as the release has been tested and validated in the target operating configurations.  The first iteration is dedicated to defect fixing, automation of regression testing, and measuring and increasing test coverage for public API. There will be no enhancements committed to CVS HEAD stream until end of iteration #1, except new features that were made available as technology preview in TPTP 4.2 release. In iteration #2, 4.2.1 release branch will be created in CVS and enhancements in plan for 4.3 release will be allowed to be committed to CVS HEAD stream. Iteration #3 is for shutting down development and get ready to release 4.3 GA.

Release Milestones
Milestone	Date	Description
Iteration 1	Friday, 04-Aug-06	Stable build - bug fixes only (CVS stream common with 4.2.1)
Iteration 2	Friday, 22-Sep-06	Stable build - enhancements and bug fixes
Iteration 3	Friday, 17-Nov-06	Stable build - shut down
	Monday, 04-Dec-06	General Availability

For a detailed development schedule of TPTP 4.3 release, click here.

Target Operating Environments

In order to remain current, each TPTP release targets reasonably current versions of the underlying operating environments.

• Java runtime (JRE) or Java development kit (JDK) 1.4
• Eclipse SDK 3.2 for Linux (GTK) , Linux (Motif), or Windows
• Eclipse Modeling Framework (EMF) SDK 2.2
• XML Schema Infoset Model (XSD) SDK 2.2

Most of the TPTP SDK is "pure" Java™ code and has no direct dependence on the underlying operating system.  The chief dependence is therefore on the Java 2 Platform itself.  The TPTP 4.3 release is written and compiled against version 1.4 of the Java 2 Platform APIs, and targeted to run on version 1.4 of the Java 2 Runtime Environment, Standard Edition.

There are many different implementations of the Java 2 Platform running atop a variety of operating systems. We focus TPTP testing on a handful of popular combinations of operating system and Java 2 Platform; these are our reference platforms.  TPTP 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 TPTP on non-reference platforms that cannot be recreated on any reference platform will be given lower priority than problems with running TPTP on a reference platform.

TPTP SDK 4.3 is tested and validated on the following target reference platforms (this list may be updated over the course of the release cycle):

Although untested, TPTP should work fine on other OSes that support the same operating system kernel and version.

Internationalization

TPTP is designed as the basis for internationalized products. The user interface elements provided by the TPTP SDK components, including dialogs and error messages, are externalized. The English strings are provided as the default resource bundles.

Latin-1 locales are supported by the TPTP SDK on all of the above operating environments; DBCS locales are supported by the TPTP SDK on the Windows, GTK, and Motif window systems; BIDI locales are supported by the TPTP SDK only on Windows operating environments.

The TPTP SDK supports GB 18030, the new Chinese code page standard, on Windows XP and 2000, and Linux.

TPTP supports ICU4J starting in 4.2 release. This will significantly increase the number of supportable locales. Products needing to localize to newer locales are enabled. German, Traditional Chinese, and Arabic are tested. 

Compatibility with Previous Releases

TPTP 4.3 will be compatible with TPTP 4.2.  The following specifies details of the various aspects of release compatibility.

• API Contract Compatibility:  Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain contract compatibility.TPTP SDK 4.3 will be upwards contract-compatible with TPTP SDK 4.2 or lower. Downward contract compatibility is not supported. There is no guarantee that compliance with TPTP SDK 4.3 APIs would ensure compliance with TPTP SDK 4.0 APIs.

• Binary (plug-in) Compatibility: TPTP SDK 4.3 will be upwards binary-compatible with TPTP SDK 4.2. Downward plug-in compatibility is not supported. Plug-ins for TPTP SDK 4.3 will not be usable in TPTP SDK 4.2. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.

• Source Compatibility: TPTP SDK 4.3 will be upwards source-compatible with TPTP SDK 4.2. This means that source files written to use TPTP SDK 4.2 APIs might successfully compile and run against TPTP SDK 4.3 APIs, although this is not guaranteed. Downward source compatibility is not supported. If source files use new TPTP SDK APIs, they will not be usable with an earlier version of the TPTP SDK.

• Workspace Compatibility: TPTP SDK 4.3 will be upwards workspace-compatible with TPTP SDK 4.2 unless noted. This means that workspaces and projects created with TPTP SDK 4.2 can be successfully opened by TPTP SDK 4.3 and upgraded to a 4.3 workspace. This includes both hidden metadata, which is localized to a particular workspace, as well as metadata files found within a workspace project (e.g., the .project file), which may propagate between workspaces via file copying or team repositories. Downward workspace compatibility is not supported. A workspace created (or opened) by a product based on TPTP 4.2 will be unusable with a product based an earlier version of TPTP. Visible metadata files created (or overwritten) by TPTP 4.3 will generally be unusable with earlier versions of TPTP.

• 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 TPTP SDK 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 TPTP PMC adopted and specialized the following Eclipse themes which represent the key focus areas for TPTP enhancements in the year ahead.

• Scaling Up - TPTP will work to enhance the support of large data volumes and processing rates in areas such as data collection, user interface and in the persistence of trace, log and statistical models and execution histories.

• Enterprise Ready - Hooks will be provided within the TPTP infrastructure to link testing tools to requirements tracking tools and defect tracking tools, thus embedding them effectively in enterprise development cycles. Changes to the data collection layers will increase interoperability with enterprise security infrastructure. In addition, there will be progressive adoption of the TPTP tools and infrastructure as a test platform for the project itself, which is in turn likely to drive refinements into the tools. An increased focus on whole-project integration testing will ensure effective interoperability amongst all TPTP components and the rest of the Eclipse environment.

• Design for Extensibility: Be a Better Platform - There will be a wide range of activities within TPTP to externalize APIs and define extension points, making the infrastructure more flexible, and more generic in application. A good example of this is integration of TPTP with WTP and BIRT for web application testing, profiling and generation of customized reports of results.

• Embedded Development - TPTP target execution environment and remote data collection framework provide capabilities that are adapted for high-end embedded systems. TPTP will seek contributions to add support for embedded systems. We are promoting use of TPTP native logging capabilities on a number of embedded target systems.

• Rich Client Platform - TPTP will use RCP for building manual test client, log analyzer and other GUI-based clients in target environments.

• Simple to Use - The existing TPTP tools were conceived as samples, rather than as exemplary, they are deficient in many areas of usability and in some cases lacking in function. The plan is that within the domains which they target they will provide a high-quality user experience out of the box. We will focus on ease of use through enhanced user documentation, tutorials, white papers, demonstrations, and a wide range of enhancements to the user interface to streamline basic processes and clarify concepts and terminology. We are focused on improving as much as possible in Release 4.3, and expect need for continuing this focus beyond 4.3.

• Enable Consistent Multi-language Support - In TPTP a significant effort will be applied in extending coverage of the trace models to represent C/C++ programs and to handle protocol activity (specifically HTTP) consistently with program activity. There will also be C/C++ APIs provided to the data collection and control layers.

• Appealing to the Broader Community - A range of initiatives will be taken to broaden the community of potential and actual users of TPTP. Technically this will include additional integration of open source test tool technologies based on JUnit, and the various hooks to JUnit in the JDT, more data collection agents – particularly focusing on open source technologies, and additional operating system and hardware platforms from which data can be collected. There will be additional marketing and an extensive outreach program to the Eclipse community for additional contribution and adoption.

Projects

The TPTP top-level project is is comprised of four projects, managed in a coordinated fashion, across which the plans items are allocated.  TPTP projects include:

• TPTP Platform Project - Provides common infrastructure in the areas of user interface, EMF based data models, data collection and communications control, as well as remote execution environments. Additionally, the Platform provides extension points for leveraging or extending these capabilities in solution specific tooling or runtimes. This includes Eclipse workbench plug-ins as well as runtime plug-ins on a target and optionally remote system.

• Testing Tools Project - Provides specializations of the TPTP Platform for testing (e.g. test editors, trace/test conversion support), and exemplary extensible tools for specific testing environments. Initially this includes three test environments: JUnit, manual, and URL testing. These specializations provide optimized editing and reporting experiences for these use cases. In the cases where a unique runtime or an implementation of a testability interface is required, it is also developed in the project. For example, the manual test execution environment provides a remotely managed user interface specifically for collecting manual test progress. This manual user interface is unique from the common execution environment for JUnit and URL testing. .

• Tracing & Profiling Tools Project - Extends the TPTP Platform with specific data collection for Java and distributed applications that populate the common trace model, additional language and protocol support is anticipated. There are also viewers and analysis services that draw data from the common trace model. Capabilities are provided to collect and analyze heap and stack information as well as generic toolkits for instrumenting running applications..

• Monitoring Tools Project - Extends the TPTP Platform for collecting, analyzing, aggregating, and visualizing data that can be captured in the log and statistical models. The typical examples are the collection of system or application resources such as CPU or memory utilization and support for the viewing, aggregation, and analysis of that data. Logs can also be transformed into a common format and model allowing for symptom and pattern analysis. The correlation of the data in these models is of particular interest when it is associated with other model instances of statistical or log data as well as traces and tests..

Features

Plan items targeted for this release represent the addition of new features or areas where existing features will be significantly reworked or enhanced.  Plan items are allocated to themes and projects indicated above.

Defects

In addition to the targeted features for this release, we plan to reduce the defect backlog. Defects are prioritized based on severity, age, and resource availability. We encourage users to report defects and we will do our best to fix them in priority order. The goal is clear backlog of major/critical/blocker defects and make reasonable progress on fixing as many as possible.

See TPTP 4.3 Defects for a listing of already fixed defects, current defect targets and backlog.

Select "4.3 [Completed | nil| I1 | I2 | I3] bugs" tabs.

Web Tools Platform (WTP)

Eclipse Web Tools Platform 2.0 Plan - DRAFT

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

This document lays out the feature and API set for the next release of Eclipse Web Tools, to be released as part of the Eclipse Europa Release, in June 2007, and usually called "WTP 2.0", for short.

This document is a draft and is subject to change, we welcome all feedback.

Web Tools 2.0 will be compatible with / based on the Eclipse 3.3 Release.

To ensure the planning process is transparent and open to the entire Eclipse community, we (the Eclipse Web Tools Requirement Group & the Web Tools PMC) post plans in an embryonic form and revise them 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 subprojects under the Eclipse Web Tools top-level project, including projects such as JSF and Dali that are currently in the incubator state. Each plan item covers a feature or API that is to be added to Web Tools, or some aspect of Web Tools that is to be improved. Each plan item will have 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.

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.

The current priority or status of each plan item is noted:

High Priority plan item - A high priority plan item is one that we have decided to address for the release (committed).

Medium Priority plan item - A medium priority 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.

Low Priority plan item - A low priority plan item is one that we addressed for a release we will only address that item if one component has addressed all high and medium priority items.

Deferred plan item - 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.

Help Wanted plan item - Typically something that started off as a Medium or Low priority, but marked "help wanted" as an acknowledgement that there are no core resources to implement the item, but if a company or person from the community wants to contribute it, then the core teams would be more willing than usual to consider any high quality patches or contributions made via bugzillas.

If not otherwise specified, an item should be assumed "medium priority". To be explicit, the appearance of an item in this draft plan should not be assumed as a commitment, but instead is simply "open development" in its form as "open planning".

Release deliverables

The release deliverables have the same form as previous releases, namely:

• Source code release for Eclipse WTP Project, available as versions (e.g. tagged "R2_0_0" in the Eclipse WTP Project)
• CVS repository
• Eclipse WTP runtime binary and SDK download with all Eclipse pre-reqs (downloadable).
• Eclipse WTP runtime binary and SDK download (downloadable).

In addition, the Eclipse WTP runtime binary and SDK will be available as part of the "Europa" update site.

Release milestones and release candidates

Release milestones will occur at roughly 6 week intervals in synchronization with the Eclipse Platform milestone releases (starting with M1) and will be compatible with Eclipse 3.3 builds. See [Europa Simultaneous Release] for the complete Europa schedule. The following are the approximate dates for WTP milestones. The approximate 1.5.x maintenance release dates are given too. The exact dates will be updated as the times grow nearer.

M1

Friday, Sep 1, 2006

Theme: run on Eclipse 3.3 stream

1.5.1

September 29, 2006

M2

Friday Oct 6, 2006

Theme: run on Eclipse 3.3 stream

1.5.2

October 31, 2006

M3

Friday Nov 17, 2006

Theme: Cleanup warnings, JUnits, Analyze Adopter Usage Reports

M4

Friday Jan 4, 2006

Theme Propose/implement APIs/Features

1.5.3

Friday February 16, 2007

M5

Friday Feb 23, 2007 (EclipseCon is 3/5)

Theme: provide good base for EclipseCon demos! :)

Most Function and API complete (e.g. 80%)

M6

Friday Apr 6, 2007

Theme: Function complete. API Freeze

RC1

Friday May 18, 2007

Theme: from M6 to RC1 will be polish, bug fixes, documentation

other RCs

if needed (June 22, latest final build)

Release

June 29, 2007

Target Operating Environments

Eclipse WTP is built on the Eclipse platform itself.

Eclipse WTP is "pure" Java code and has no direct dependence on the underlying operating system. The chief dependence is therefore on Eclipse. The 2.0 release of the Eclipse WTP Project is written and compiled against an appropriate version of Java as specified by the Execution Environment of each plugin. In general, Java 5 of the Java Platform (Java SE 5.0) will be needed to use WTP as a whole, but, the Execution Environment will be specified for each plugin, starting at J2SE 1.4, which is the current requirement, and then only moved up to Java SE 5 when some change made that requires it. WTP adopters should expect that full functionality will require running on a Java SE 5.

Eclipse WTP is mainly tested and validated on Windows platforms, it should run on all platforms validated by the platform project:

Eclipse Target Operating Environments

Servers integrated into Eclipse WTP deliverables will be tested and validated on the same platforms listed above. Tests for other platforms will be relying on the community support.

Internationalization'

The Eclipse WTP 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. Other language support, if any, will rely on the community support.

Compatibility with Other WTP Releases

Project Compatibility:

• Binary compatibility with 1.5 and 1.0 projects - users should need to take no special actions to use projects

from either of these WTP releases with the 2.0 version

• WTP 2.0 should be able to open workspaces created with WTP 1.5
• WTP 2.0 should be usable in a team environment where some team members use WTP 1.5 and team members share projects through a source code control system such a

CVS or Subversions. Specifically, A WTP 1.5 should be able to create a project, check it in to the repository. A WTP 2.0 user should be able to check it out, work on it, and check it back in. A WTP 1.5 should then be able to check it back out and continue to work it on.

• By default, WTP 1.5 should work on projects created by WTP 2.0 users and shared via a repository. Artifacts created by WTP 2.0 that are consistent with 1.5

features should not break WTP 1.5, and where possible WTP 1.5 should either ignore or tolerate any new artifacts in WTP 2.0 and subsequent releases. Attempts to use (or convert to) new 2.0 functionality that cannot be made backwards compatible with 1.5 must be clearly identified in documentation.

API Compatibility:

• WTP 2.0 will preserve (public, declared) API compatibility with the 1.5 release, both in terms of syntax and behavior
• A plug-in that is developed on WTP 1.5 and that uses no internal methods should run correctly without recompilation on WTP 2.0
• A plug-in that is developed on WTP 1.5 and that uses no internal methods should recompile without error on WTP 2.0
• WTP 2.0 should provide migration notes and adequate notification and lead time to adopters for any internal code that is removed in WTP 2.0
• WTP 2.0 should continue to provide adopters with the ability to register their code usage reports and to be consulted in any proposed changes to internal code.

WTP 2.0 will take into account adopter feedback on proposed changes to internal code, but reserves the right to change internal notwithstanding that feedback.

Eclipse WTP 2.0 deliverables will be compatible with Eclipse 3.3. No special attention will give for being compatible with previous Eclipse versions.

Eclipse WTP Subprojects

The Eclipse WTP consists of four subprojects. Each subproject is covered in its own section:

Web Standard Tools (WST)

J2EE Standard Tools (JST)

Java Server Faces Tools (JSF, incubating)

JPA (Dali/JPA, incubating)

AJAX Tools Framework (incubating)

The JSF, Dali, and ATF incubators SHOULD exit incubation and become normal components in WTP 2.0. A partial list of the new WTP components is:

• JSF - org.eclipse.jst.jsf
• Dali - org.eclipse.jst.jpa
• ATF - org.eclipse.wst.js, org.eclipse.wst.ajax

Items listed reflect new features of the Web Tools Platform, or areas where existing features will be significantly reworked. Common goals are listed in the “Common goals” area.

TBD (Each item indicates the components likely affected by that work item (many items involve coordinated changes to several components). Numbers in parentheses link to bugzilla problem reports for that plan item)

Note that JSF and JPA/Dali are incubating projects at the moment. Users should expect API and tool refinements in these areas, with a likelihood for more rapid (and extensive) revisions than in the base WTP code, along with initial API declarations in the 2.0 release.

Major themes

Improve Quality

Focused effort will be made to reduce bug backlog, improving test coverage, performance and performance testing, ISV documentation and examples, usability and UI consistency.

Adopter readiness

• Extensibility

Provide extension points for adopters to add-in implementation functionality, such as for JEE5 features, publishing support, add to project creation pages, etc.

• productization support [125751]
• Componentization

improve feature split Subsystem and Features document

• improve API coverage

convert provisional APIs in a careful, well reviewed way, to minimize adopter breakage

Improved Provisioning of Third Party Content

• Participate in Orbit project to move our commonly needed third-party content to a common Eclipse repository.
• help create remote Update Manager sites hosted by providers of third party content required by WTP to streamline the process of adopting new versions

users should be able to acquire revisions of third party content in a more timely fashion

begin by creating a common site at Apache for components such as Axis2, Woden, Tomcat, Geronimo

• maintain and expand current site at SourceForge as required
• create new site at ObjectWeb for Jonas

Help

• adopt DITA for Help content
• work with DITA-OT project at SourceForge to improve integration of build process with PDE

Web Standard Tools subproject

XML Editing

• Improve Code folding
• Migrate to Platform Undo (IOperationHistory)
• Improved formatting, e.g. whitespace handling, WYSIWYG (for DITA, DocBook, etc.)
• Run in Eclipse RCP
• Large document performance enhancements

Architectural harmonization

DTP

Remove all Data access tools from WTP and instead use the corresponding components from DTP. We should take a two-phase approach.

• Phase 1 - Achieve functional parity with WTP 1.5, i.e. get back to where we currently are, but using DTP.

• Phase 2 - Exploit new DTP capabilities. DTP has much broader scope than the WTP 1.5 Data tools, e.g. in connection management, server exploration. We need

to do an architectural assessment of current WTP capabilities and adopt superior alternatives available in DTP.

WTP currently has only a small dependency on RDB, which might be migrated to DTP or, perhaps, will be replaced by a more a generic, loose, optional dependency.

JPA (Dali), however, will have a stronger dependency on DTP, so, DTP will, in the end, be listed as one of the pre-reqs for WTP as a whole. (But, the goal is, if JPA is not installed then DTP will not be required).

STP

Investigate areas of overlap with STP, especially in the areas of Web services, and ensure that existing WTP components can be extended as required by STP.

TPTP

Improve integration with TPTP, especially in the area of profiling servers.

PHP Tools Project

Investigate if the Apache Web server adapter should be moved into wst.server. Investigate if other generic components currently in the PHP project should be moved in WTP.

Need to investigate and support their use of our SSE Incremental DOM parser and A.) not break them :) or B.) provide API.

Web Services Support

• Provide extensibility for providers of web service implementations

• New WS-I Profiles, e.g. RAMP
• WS Security
• WS Policy
• Axis 2.0
• SOAP 1.2
• WSDL 2.0 - adopt Apache Woden 1.0

J2EE Standard Tools

Java EE 5

• JPA/Dali (Draft Milestone Plan)
• JSF
  • JSF 1.2
• JSP
  • Complete and Improve JSP 2.0 support
  • Support JSP 2.1
• Provide extensibility for providers of JEE5 implementations
• Java EE 5 models - the models must be upgraded to handle Java EE 5 without ANY API breakage. Existing clients MUST continue to work without recompilation.

If existing clients are recompiled with the new model, then compilation errors MUST NOT occur (note: we assume that existing clients will not break in any way if they only use the published API - code that relies on internal interfaces MAY break)

• investigate: import a JEE5 project (help wanted)
• investigate: export/publish a JEE5 project (help wanted)
• validate a JEE5 project (help wanted)
• JSR 175 - support Java EE 5 specifications for annotation based programming, e.g. for EJB 3.0, JPA, Web services
  • JSR 181 - Web Services
  • JSR 220 - EJB 3.0, JPA

Web Services

• JSR 109 - for Web container
• support for generic, compliant runtime, e.g. hosted at GlassFish

Server Runtime

• JSR 88 Support, Advanced Server Support for one/multiple open source J2EE server
• Server runtime facet enhancements (link TBD)
• Migrate existing bundled server adapters to the remote server adapter support - our direction should be to have server providers host their own adapters as they

currently do for their runtimes. Server providers should also be encourage to use the remote server runtime installation framework (currently used by Geronimo)

SOA Tools Platform