Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Web Tools Platform Release 3.0 Requirements"

(Architectural harmonization)
Line 46: Line 46:
 
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.
 
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===
 
===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 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 that need to 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 ===
 
=== 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).  
 
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).  

Revision as of 15:11, 16 July 2007

Note: This is a draft of the requirements document and is expected to change.

Last revised: July 16, 2007

Please send your feedback on this draft document to the wtp-dev@eclipse.org developer mailing list.

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 the WTP Component leads.

Release Themes

Themes and their priorities communicate the main objectives and their importance to the project. 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

(Note: The following definition is provided by the Eclipse Requirements Council

Eclipse themes are described in one of four categories.

  • Active themes are those that are ongoing and changing. From time to time, some Active themes will become Persistent and Pervasive.
  • Persistent and Pervaisve 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. These include support for

  • OS
  1. Windows Vista
  • Java
  1. Java SE 6.0

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
  • WTP should provide enhanced user documentation, tutorials, white papers, demonstrations.

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 that need to 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.

This includes:

  • Assuring release-to-release migration is supported (e.g., resources, workspaces, API, as appropriate).
  • Assuring API compatibility release-to-release, including testing for upward compatibility
  • 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

Requirements

General Project-wide requirements

Reduce use of cross-project non-APIs

Back to the top