Introduction

This document captures the requirements for the Web Tools Platform Project Release 3.0. The inputs for this requirement will be from the WTP community of Users, Adopters and Developers and the Eclipse Requirements Council. The document will be maintained by the WTP PMC members and Component leads.

Release Themes

Themes and their priorities communicate the main objectives of the project and their importance. The following themes are derived from those defined by the Eclipse Requirement council for the Eclipse Ganymede release and from the WTP 2.0 release themes. These will be prioritized based on the community feedback. New themes could be synthesized from the requirements submitted by the community.

Theme Categorization

Active themes are those that are ongoing and changing. From time to time, some Active themes will become Persistent and Pervasive.

Persistent and Pervasive themes are not time or release specific. Persistent and Pervasive themes are not only a signal of importance, but permanence.

Deferred Themes are not an indication of priority, but are an indication that there are technical or resource inhibitors preventing them from becoming an Active Theme. Deferred themes are a signal to the ecosystem that help is needed.

Pending Themes are new and interesting themes that have not yet been properly explored and discussed to become an Active theme.

Active Themes

Platform Support

WTP will support the platforms certified by the Eclipse Platform project. The following platforms will be added in this release.

Support for Rich Internet Applications (RIA)

"Web 2.0" is a significant technology trend (see Wikipedia discussion on Web 2.0) that has enabled the development of a new generation of web sites that provide a rich and user-friendly experience in a wide variety of applications. As developers shift from the development of traditional web sites to Web 2.0-style sites, WTP should support developing applications that leverage Web 2.0 techniques such as Ajax (and Flex?).

Java EE 5.0 Support

Support for the Java EE technologies is one of the main charter of WTP. The WTP 2.0 release supports some of the key technologies in the Java EE 5 technologies stack. The next releases of WTP should provide complete support for all the relevant technologies in Java EE 5.

Improve the "Out of the box" Experience

This is one of the critical objectives of this release. WTP should explore ways to make it easy for a (first-time?) WTP user to become productive in using its features. Examples include:

Use of the Eclipse Packaging Project to offer additional role-based packages (such as Web Development kit, AJAX Development Kit, XML Development kit).

Continue to work on the Release 2.0 theme,' Improved Provisioning of Third Party Content'. WTP should help create remote Update Manager sites hosted by providers of third party content required by WTP such as a site at Apache for components such as Tomcat, Axis2 etc.

WTP should provide task-based Cheat Sheets, tutorials, screencast for the most common set of tasks

Ease of Use

Features provided by WTP should be simple to use for users with widely-varying backgrounds and skill sets.

WTP User Interface should be consistent and should follow the Eclipse User Experience Guidelines.

Usability and Accessibility reviews should be done for the most common task flows. Cheat Sheets should be provided to assist users in performing tasks

Persistent and Pervasive Themes

Design for Extensibility

WTP is a platform that is used by adopters to extend its functionality. This theme is about continuing to ensure the success of its adopters by promoting new API's and Extension points. These should be backed with robust Junit tests and good documentation.

Scaling Up

This refers to the need for WTP to deal with development and deployment on a larger and more complex scale. WTP should spend focused effort on performance testing and improvement when dealing with extremely large projects and workspaces.

Architectural harmonization

WTP should continue to improve the interaction/integration with other projects in the Eclipse ecosystem. Uptake of new features from the dependent projects such as the Eclipse Platform, improved integration with TPTP are some of the items to be considered for this release. WTP should also review functionalities in the project that can be moved to the base/dependent platforms. (It is also a good idea to apply this theme on sub-projects and components within WTP.)

Accessibility Compliance

Every project should support and make a statement on their accessibility compliance. In the U.S., this means Section 508 compliance; in the European Union, this is the Web Accessibility Initiative of the World Wide Web Consortium (W3C).

Internationalization & Localization

Every project should support both internationalization and localization:

Internationalization (I18N) Each project should be able to work in an international environment, including support for operating in different locales and processing/displaying international data (dates, strings, etc.).

Localization Each project should provide an environment that supports the localization of the technology (i.e. translation). This includes, but is not limited to, ensuring that strings are externalized for easy translation.

Where possible, projects should use an open and transparent process to create, maintain and deliver language packs translated into multiple languages in a timely manner. The primary languages to consider are: English, Simplified Chinese, Traditional Chinese, Japanese, French, German, Spanish.

Upgrade Path

Upward compatibility is a critical aspect of developer satisfaction and community growth. Smooth upward migration is therefore a core Theme that all projects must consider.

Clear statements indicating which APIs are intended for internal use only (and are not gaurenteed to be upward compatible)

Providing tools that automate the migration process where possible

Deferred Themes

Pending Themes

Enterprise Ready

Technology Trends

Requirements

Status of a requirement

The current status of a requirement can be one of the following categories.

Proposed

These are requirements that are being considered for this release. These are items that are either being investigated or items that the project would like to explore but are not yet Committed. Most of the requirements should start as proposed items. After a review and some amount of detailed planning, their status will either become committed or deferred.

Committed

These are requirements that the project team is definitely going to address in the release. Resources and some amount of detailed plans have been identified for such items.

Deferred

These are valid requirements that started in a Proposed state but will not be addressed in this release. Each such item will have a brief note explaining the cause for the deferral.

Flags on a requirement

A requirement can have these additional flags.

Help Wanted

These are valid requirements in the 'Propsed' or 'Defferred' status that require volunteers to work on them. These are especially good candidates for companies or individuals who want to get involved with WTP in a large way.

This flag is used to mark items as they are mostly finished. While the items might continue to have bugs fixed etc. until the final release, we expect each milestone will have some items to mark as "complete", such as those going into a New and Noteworthy document for that milestone. This flag is a good indication that something is ready to be fully tested, documented, etc.

General Project-wide requirements

Proposed

Committed

Platform Support

Support for Windows Vista: WTP will test and verify on Windows Vista OS

When using non-APIs, projects MUST have opened bugzillas against the other projects and include references to those bugzillas in the release notes and the :release review slides. Projects MUST also have a plan for addressing the non-API issue in their next major release.

When using non-APIs, projects MUST NOT expose those consumed non-APIs through the project's own APIs. We cannot even begin to explain what a bad idea that would be.

When using non-APIs, projects MUST participate in the same maintenance releases as the projects they are using from.

WTP should address bug backlog.

Deferred

Common

Faceted Project Framework

Committed

Performance improvements for the facets selection panel when the number of facets and runtimes grows.

The prevalent thinking is that the dialog approach presented elsewhere in this wiki is better than the "suppress the page via a checkbox" approach suggested in this bug

Improve the way information about a facet is presented. Make necessary information available and easily accessible. Remove unnecessary information where possible. The current proposal is to center these improvements around using the space on the RHS of the facets selection panel to present facet information. The targeted runtimes panel would then slide over that.

Repackage the faceted project framework as a separate distribution. This involves repackaging into a wtp-independent name space org.eclipse.common.fproj (approval pending) and pulling documentation into a separate plugin. This work is to be done in a way that maintains backwards compatibility. Two distributions should be provided: runtime and sdk (includes src and docs). 160245

Work with the server tools team and other interested parties to create the "Runtime Environment Modeling Framework" (final name TBD that would unify the runtimes api in server.core and in the faceted project framework. This would result in simpler api and richer abilities to describe a runtime environment. The new framework should be packaged as a separate distribution. 159169

Contact the PDE team regarding using this api for managing OSGi targets platforms. Better integration and similar behavior between WTP and PDE will be of benefit to users as server-based OSGi development becomes more common. It would be good if it was possible to manage Java EE and OSGi runtimes/servers from a single view.

Blur the lines between runtimes and servers. The existing separation between the two is a source of significant user confusion. A server should just be a "startable" runtime.

Give more UI freedom to server adapter provider. It should be possible to provide a single wizard that asks the user for install location and determines the version of the runtime from that (right now the user is required to select the version first). It should be possible to provide a single wizard that can selectively create a "runtime", a "server", or both depending on user input.

Server Tools

Proposed

Committed

Completed

Servers view & Server editor - Continue to improve the UI and usability of the server framework views & editors. Some examples are improved popups and control of actions in the Servers view, and adding field assist and better layout to the server editor.

Server editor timeout - The timeout settings contains inconsistency in API and UI, it needs to be revamped into something more consistent and user friendly. bug#121593

Auto-publish settings - The global auto-publish settings need to be revamped into something more consistent and user friendly.

Ease of Use

Installable servers/runtimes - Continue to improve the support for downloadable server adapters (potentially basing on the new platform provisioning work), and reimplement downloadable runtime zip support to not be based on update manager sites.

Design for Extensibility

Continue to extend the server framework API in response to bug requests and internal usage.

Deferred

See Faceted Project Framework section above for some overlapping requirements.

Investigate the possibility of positioning server tools (or a derived framework) as the server lifecycle and artifact publishing framework for all of Eclipse. For instance, as server-based OSGi development becomes more prevalent we would not want to end up in a situation where there are two server management framework (one in WTP and one in PDE). It's been suggested that Provisioning can become the unifying api for this (and unifying UI can then be built on top of provisioning). If that's the direction that WTP wants to head in, then WTP participation in Provisioning will be required to make sure that the Provisioning api can serve all of Java EE publishing use cases (such as incremental publish).

Enable the generation of sample JSPs to test Axis2 Web service - 196953

AJAX Toolkit Framework (ATF Project, incubating)

Proposed

The ATF will remain in incubation, while the project continues to build a community of committers.
More specific plans will be published here as the WTP milestones progress. See
ATF Roadmap for some possibilities.

The Eclipse and WTP community should feel free to query and add to ATF's enhancement requests,
if anyone has any specific requests or contributions they'd like to document.