Eclipse Web Tools Project DRAFT 2.0 Plan

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

This document lays out the feature and API set for the next feature release of Eclipse Web Tools after 1.5, designated release 2.0.
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 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.

Release deliverables

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

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

Release milestones and release candidates

Release milestone occurring at roughly 6 week intervals in synchronisation with the Eclipse Platform milestone releases (starting with M1) and will be compatible with Eclipse 3.3 builds. See Callisto Simultaneous Release for the Eclipse Platform schedule from 2006 on which the 2007 calendar will be based. (Note that this is not yet available, and that the dates below are simply a placeholder carried over from last year.)

Target Operating Environments

Eclipse WTP is built on the Eclipse platform itself.

Most of the 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 version 5 of the Java Platform APIs, and targeted to run on version 5 (aka 1.5) of the Java Runtime Environment, Standard Edition.

Eclipse WTP is mainly tested and validated on Windows platforms, it should run on all platforms validated by the platform project (note that this link below is outdated but a new version is not yet available):

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

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.

Web Standard Tools subproject

Architectural harmonization

DTP

Adopt 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 - Acheive functional parity with WTP 1.5, i.e. get back to where we currently are, but using DTP.

Phase 2 - Exploit new DTP capabilites. 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.

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.

Web Services Support

WS Security

WS Policy

Axis 2.0

SOAP 1.2

WSDL 2.0 - adopt Apache Woden 1.0

WSDL 2.0

WSDL is a key Web service artifact. WSDL 2.0 is the W3C standard and has many new features that align Web services with Web architecture, especially in the
area of HTTP support and REST style Web services. All WTP tools that currently process WSDL 1.1 should be upgraded to handle WSDL 2.0. The integration should be seamless in the sense that the tools should understand both WSDL 1.1 and WSDL 2.0. All wsdl files will use the same file extension, i.e. *.wsdl. These tools include:

WSDL editor - editor should detect namespace

WSDL validator - validator should detect namespace

Web service explorer

Web service test tools - the WS-I test tools should be extended to support services described by WSDL 2.0 based on the W3C standard, e.g. verify the message log conforms to a WSDL 2.0 description

Web service wizard - e.g. via integration with Axis 2.0 to support top-down, bottom-up, and client code generation based on WSDL 2.0

J2EE Standard Tools

Java EE 5

JPA/Dali

JSF

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)