Difference between revisions of "Web Tools Platform 2.0 Plan"

From Eclipsepedia

Jump to: navigation, search
(Architectural harmonization)
(Release milestones and release candidates)
 
(43 intermediate revisions by 10 users not shown)
Line 1: Line 1:
=Eclipse Web Tools Project DRAFT 2.0 Plan=
+
=Eclipse Web Tools Platform 2.0 Plan - DRAFT=
  
'''Revised draft''' April 25, 2006 (by Tim Wagner / based on WTP Project 1.5 Plan
 
and Eclipse Project DRAFT 3.3 Plan)
 
  
''Please send comments about this '''draft plan''' to the'' wtp-pmc@eclipse.org ''mailing list.''  
+
''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 feature release of Eclipse Web Tools after 1.5, designated release 2.0.
+
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
This document is a draft and is subject to change, we welcome all feedback.  
+
usually called "WTP 2.0", for short.
  
'''Web Tools 2.0 will be compatible with / based on the Eclipse 3.3 Release.'''
+
This document is a draft and is subject to change, we welcome all feedback.
  
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.  
+
Web Tools 2.0 will be compatible with / based on the Eclipse 3.3 Release.
  
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.
+
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 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.  
+
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.
  
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 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.
  
 +
<del>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.</del>
  
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).
+
The current priority or status of each plan item is noted:
  
'''Medium Priority''' plan item - A medium priority plan item is one that we are considering addressing for the release.
+
'''High Priority''' plan item - A high priority plan item is one that we have decided to address for the release (committed).
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
+
'''Medium Priority''' plan item - A medium priority plan item is one that we are considering addressing for the release.
component has addressed all high and medium priority items
+
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.
  
'''Deferred''' plan item - A reasonable proposal that will not make it in to this release for some reason is marked as deferred with  
+
'''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
a brief note as to why it was deferred. Deferred plan items may resurface as committed plan items at a later point.  
+
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==
 
==Release deliverables==
  
The release deliverables have the same form as previous releases, namely:  
+
The release deliverables have the same form as previous releases, namely:
  
* Source code release for Eclipse WTP Project, available as versions tagged "R2_0" in the Eclipse WTP Project
+
* Source code release for Eclipse WTP Project, available as versions (e.g. tagged "R2_0_0" in the Eclipse WTP Project)
 
* CVS repository
 
* CVS repository
 
* Eclipse WTP runtime binary and SDK download with all Eclipse pre-reqs (downloadable).
 
* Eclipse WTP runtime binary and SDK download with all Eclipse pre-reqs (downloadable).
 
* Eclipse WTP runtime binary and SDK download (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 "Callisto '07" update site.
+
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 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 [http://www.eclipse.org/projects/callisto.php 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.)
+
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.
  
The milestones and release candidates are:
 
  
* M4  -    January 13, 2006
+
;M1:Friday, Sep 1, 2006
* M5  -    March 3, 2006 (planned API freeeze)
+
:Theme: run on Eclipse 3.3 stream
* M6/RC0  -    April 14, 2006 (This is Feature Freeze except for JSF and Dali).  
+
;1.5.1:September 29, 2006
                            (this 4/14 date is also called both RC0 and RC1 in Callisto plan).
+
;M2:Friday Oct 6, 2006
* RC1 -    April 21, 2006
+
:Theme: run on Eclipse 3.3 stream
* RC2 -    May 5, 2006 (tiny grace period where any safe fix can be made).  
+
;1.5.2:October 31, 2006
* RC3 -    May 19, 2006 (component lead approval required for all fixes)
+
;M3:Friday Nov 17, 2006
* RC4 -    May 31, 2006 (planned code freeze, PMC approval required for all fixes)
+
:Theme: Cleanup warnings, JUnits, Analyze Adopter Usage Reports
* RC5 -    June 20, 2006 (PMC approval and adopter sign-off required for all fixes)
+
;M4:Friday Jan 4, 2006
* RC6 -    Jume 28, 2006 Golden Master
+
:Theme Propose/implement APIs/Features
* Release - June 30, 2006 - WTP 1.5 Release (part of the "Callisto" joint release)
+
;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
 +
;RC0:Friday May 18, 2007
 +
:Theme: from M6 to RC1 will be polish, bug fixes, documentation
 +
;other RCs:TBD
 +
:(June 22, latest final build)
 +
;Release:June 29, 2007
  
 
==Target Operating Environments==
 
==Target Operating Environments==
Line 67: Line 93:
 
Eclipse WTP is built on the Eclipse platform itself.
 
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 "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 (note that this link below is outdated but a new version is not yet available):
+
Eclipse WTP is mainly tested and validated on Windows platforms, it should run on all platforms validated by the platform project:
  
[http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_2.html#TargetOperatingEnvironments#TargetOperatingEnvironments Eclipse Target Operating Environments]
+
[http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_3.html#TargetOperatingEnvironments 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.  
+
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'''
+
'''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.
+
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==
 
==Compatibility with Other WTP Releases==
  
Project Compatibility:  
+
Project Compatibility:
  
 
* Binary compatibility with 1.5 and 1.0 projects - users should need to take no special actions to use projects
 
* 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
+
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:  
+
API Compatibility:
  
* WTP will preserve (public, declared) API compatibility with the 1.5 release
+
* 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
Eclipse WTP deliverables will be compatible with Eclipse 3.3. No special attention will give for being compatible with previous Eclipse versions.  
+
* 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==
 
==Eclipse WTP Subprojects==
  
The Eclipse WTP consists of four subprojects. Each subproject is covered in its own section:  
+
The Eclipse WTP consists of four subprojects. Each subproject is covered in its own section:
  
[http://eclipse.org/webtools/wst/index.html Web Standard Tools (WST)]
+
[http://eclipse.org/webtools/wst/main.html Web Standard Tools (WST)]
  
[http://eclipse.org/webtools/jst/index.html J2EE Standard Tools (JST)]
+
[http://eclipse.org/webtools/jst/main.html J2EE Standard Tools (JST)]
  
 
[http://www.eclipse.org/webtools/jsf/index.html Java Server Faces Tools (JSF, incubating)]
 
[http://www.eclipse.org/webtools/jsf/index.html Java Server Faces Tools (JSF, incubating)]
  
[http://www.eclipse.org/webtools/dali/index.html JPA (Dali/JPA, incubating)]
+
[http://www.eclipse.org/dali JPA (Dali/JPA, incubating)]
  
Items listed reflect new features of the Web Tools Platform, or areas where existing
+
[http://www.eclipse.org/atf/ AJAX Tools Framework (incubating)]
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)
+
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:
  
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.
+
* JSF - org.eclipse.jst.jsf
 +
* Dali - org.eclipse.jst.jpa
 +
* ATF - org.eclipse.wst.js, org.eclipse.wst.ajax
  
==Common goals==
+
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===
 
===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 [https://bugs.eclipse.org/bugs/show_bug.cgi?id=125751 [125751]]
 
* productization support [https://bugs.eclipse.org/bugs/show_bug.cgi?id=125751 [125751]]
* improve feature split [http://www.eclipse.org/webtools/development/arch_and_design/subsystems/SubsystemsAndFeatures.html Subsystem and Features document]
+
* Componentization
* improve API coverage (convert additional provisional areas to APIs)
+
:improve feature split [http://www.eclipse.org/webtools/development/arch_and_design/subsystems/SubsystemsAndFeatures.html 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
 +
* <del>maintain and expand current site at SourceForge as required </del>
 +
* 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==
 
==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.)
 +
* <del>Run in Eclipse RCP</del>
 +
* Large document performance enhancements
  
 
===Architectural harmonization===
 
===Architectural harmonization===
  
Adopt DTP. Remove all Data access tools from WTP and instead use the corresponding components from DTP. We should take a two-phase approach.
+
==== DTP ====
 +
 
 +
Remove all Data access tools from WTP and instead use the corresponding components from DTP. <del>We should take a two-phase approach</del>.
 +
 
 +
* <del>Phase 1 - Achieve functional parity with WTP 1.5, i.e. get back to where we currently are, but using DTP.</del>
 +
 
 +
* <del>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.
 +
</del>
 +
 
 +
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 ====
  
Phase 1 - Acheive functional parity with WTP 1.5, i.e. get back to where we currently are, but using DTP.
+
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.
  
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.
+
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===
 
===Web Services Support===
* WS Security
+
 
* Axis 2.0
+
* Provide extensibility for providers of web service implementations
* SOAP 1.2
+
 
 +
* <del>New WS-I Profiles, e.g. RAMP</del>
 +
* <del>WS Security</del>
 +
* <del>WS Policy</del>
 +
* <del>Axis 2.0</del>
 +
* <del>SOAP 1.2</del>
 +
* <del>WSDL 2.0 - adopt Apache Woden 1.0</del>
  
 
==J2EE Standard Tools==
 
==J2EE Standard Tools==
  
 
===Java EE 5===
 
===Java EE 5===
* JPA/Dali
+
* JPA/Dali ([[Dali_1.0_planning|Draft Milestone Plan]])
 
* JSF
 
* JSF
* Java EE 5 models
+
** JSF 1.2
 +
* JSP
 +
** Complete and Improve JSP 2.0 support
 +
** Support JSP 2.1
 +
* Provide extensibility for providers of JEE5 implementations
 +
* <del>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)
 +
</del>
 +
* 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 Support===
+
=== Web Services ===
* JSR 181 (Web Services)
+
* JSR 109 - for Web container
 +
* support for generic, compliant runtime, e.g. hosted at GlassFish
  
 
===Server Runtime===
 
===Server Runtime===
 
* JSR 88 Support, Advanced Server Support for one/multiple open source J2EE server
 
* JSR 88 Support, Advanced Server Support for one/multiple open source J2EE server
 
* Server runtime facet enhancements (link TBD)
 
* 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)

Latest revision as of 15:07, 29 March 2007

Contents

[edit] 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".


[edit] 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.

[edit] 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
RC0
Friday May 18, 2007
Theme: from M6 to RC1 will be polish, bug fixes, documentation
other RCs
TBD
(June 22, latest final build)
Release
June 29, 2007

[edit] 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.

[edit] 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.

[edit] 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.

[edit] Major themes

[edit] 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.

[edit] 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

[edit] 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

[edit] Help

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

[edit] Web Standard Tools subproject

[edit] 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

[edit] Architectural harmonization

[edit] 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).

[edit] 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.

[edit] TPTP

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

[edit] 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.

[edit] 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

[edit] J2EE Standard Tools

[edit] 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

[edit] Web Services

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

[edit] 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)