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

Web Tools Platform Release 3.0 Requirements

Revision as of 13:38, 27 March 2008 by Thatnitind.gmail.com (Talk | contribs) (Source Editing)

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

Last revised: --2008-03-27

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

Back to WTP Requirements Main

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

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

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

For a list of platforms supported in WTP 2.0, see Eclipse Target Operating Environments

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

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

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

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.

Complete File:Checkmark-10x10.gif

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

Platform Support

  1. Support for Windows Vista: WTP will test and certify on Windows Vista OS

Others

  1. Reduce use of cross-project non-APIs
    • From Eclipse Planning Council Minutes
    • Projects SHOULD NOT use non-APIs from other projects, but if you must then...
    • 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.
  2. WTP should address bug backlog.

Committed

Deferred

Common

Faceted Project Framework

Committed

  • 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
  • Performance improvements for the facets selection panel when the number of facets and runtimes grows.
  • Usability Improvements
  • De-emphasize the facets selection panel for basic cases.
  • 143075 - Allow the user to bypass facets page if preset is selected
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.
  • 135950 - Support dynamic help for individual facets.
  • 191712 - Facets description hover help is not sufficient
  • 198116 - Facet constraint display issues

Deferred

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

Validation Framework

Proposed

  • Provide validation API and refinements in the framework. 187193

Committed

Deferred

Source Editing

SSE, JavaScript, XML, JSP, XSD, HTML, CSS, DTD


Committed

Architectural Harmonization
  • Port and enhance our validators to take advantage of the New Validation framework (218718)
Design for Extensibility
Improve the "Out of the box" Experience
  • Complete our Java EE 5 (JSP 2.0) Support (124288)
    • Support for <jsp:attribute> (197220)
    • Improved JSP quote handling (150794)
  • Improved JavaScript support (205858,220289)
Ease of Use
Scaling Up


Deferred

  • Migrate to Platform Undo (IOperationHistory) (191754)
  • File encoding specified from web.xml 104785
  • Support JSP 2.1
  • Provide an API org.xml.sax.EntityResolver class based on the Common URI Resolver
  • Configurable Code folding
  • Run in Eclipse RCP
  • Support for EFS
  • WYSIWYG (for DITA, DocBook, etc.)
  • Overhaul the XML Editor's Design page
  • Offer a fault-tolerant STAX parser
  • Provide syntax coloring and structures in compare viewers
  • Allow for a default grammar by content type (210413)
  • Provide infrastructure on which to build Facelet Support (206370)

Java EE Tools

Proposed

  1. Java EE 5 module-specific validator support 198900

Committed

  1. Allow up-level spec version changes for JEE facets 182210194926
  2. Simplify Java EE DD model APIs
    1. Existing model clients MUST continue to work without recompilation(Legacy models in JEE5 projects)198672
    2. Public wrapper APIs for specific module types (e.g. IWebProject,IEnterpriseApplication, WebApp)163231187699
    3. Public Utility classes 190048
  3. EAR Archive import that discriminates modules for annotated data following Spec rules 194679
  4. Enhancements in the Servlet, Filter and Listener wizards 146694 191929 198937 205330 205333
  5. Add action to generate deployment descriptor for Java EE 5 projects 196271
  6. Adding more extensibility/Pluggable features to Java EE and Web Perspectives 216327
  7. Navigator(Project Explorer) content for Java EE models
    1. Extensible/Pluggable Java EE5 model framework that supports merged view of DDs and source annotations 198815
  8. Package library directory(EAR lib directory support) 207826

Completed

  1. ModelProvider API updates - listeners 198674
  2. Filter and Listener Wizards 199105 199106
  3. Rearrangement of the toolbar in the Java EE perspective 174308
  4. Enhancements in the Web 2.4 navigator content 208767
  5. EJB3 Session Bean wizard 199119
  6. Enhancements in the Servlet, Filter and Listener wizards 127567 209206 208766 181536
  7. EJB3 MDB Wizards 199121
  8. Extensible EJB3 Session Bean wizard 213927
  9. Classpath entry publish/export support:
    1. Support class folder cp entries 189943
    2. Support J2EE Module Dependencies UI on Utility projects referenced by dynamic web project 184094
    3. Preferences 185112

Deferred

  1. EJB Bean properties and overview views like the Entity Bean ones in Dali
  2. Deployment descriptor editor(s) for all Java EE 5 DD files 173924
  3. Classpath entry publish/export support:
    1. Use classpath entry publish/export support to handle most J2EE dependencies (design details; bugzilla enhancement: 116856)
    2. Support project cp entries 184125

Java Persistence API (JPA) Tools (Dali Project)

Proposed

Usability/Integration (take further advantage of Eclipse integration)

  • Mapping file creation wizard 200268

Committed

Extensibility

  • Define Public(provisional) API 178653
  • Concrete context model 214915

More Spec Support

  • Persistence.xml editing 130580
  • Named Query support in the UI 186439
  • Support IdClass 137799
  • Generators on Entity level 127337
  • Add UI for complete Table and Column definition 198982

Usability/Integration (take further advantage of Eclipse integration)

  • Project Explorer contribution
  • Support adding JPA functionality to an existing Java project 179054

Enhance Validation

  • Broaden scope of current validation

EclipseLink support

  • Support basic features in EclipseLink 220226
    • DDL Generation
    • Persistence.xml properties
    • A subset of custom annotations

Deferred

Extensibility

  • Entity Generation extensibility 175177

More Spec support

  • Support Callbacks 198985
  • Multiple Persistent Unit support (Non-overlapping – classes must be listed in persistence.xml) 194833
  • Java Class file support 197069
  • Cross project references

Usability/Integration (take further advantage of Eclipse integration)

  • Quick Fixes
  • Java UI indicator to show where XML is overriding Java annotations
  • ORM XML element/attribute value completion 188940

JavaServerFaces (JSF) Tools

Proposed

Feature completeness

  1. Enhance Web Page Editor
    • Extensibility
    • Syntactic and Semantic Validations
    • 126947Quick Fix and Quick Assist

Committed

  1. 206103 Support for XHTML as a view description language for JSF
  2. 183302 Web Page Editor support for XML format JSPX file
  3. 219160 Tag library support for Apache MyFaces Trinidad

Completed

  1. 206100 Enhancements to the WPE Property pages
  2. 175109 Hyperlink and Hover Help in WPE Source Tab.

Deferred

  1. Enhance Design-time Metadata Framework 198599

Technology Trends

  1. Support for Page Templates

Ease of Use

  1. Simplify the binding of a JSF component to its datasource
  2. Simplify creation of a JSF Page

Server Tools

Proposed

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

Committed

Ease of Use

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

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

Completed

  1. 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.
  2. Servers view tooltip bug#197541
  3. 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
  4. Auto-publish settings - The global auto-publish settings need to be revamped into something more consistent and user friendly.

Deferred

Web Services

Proposed

Axis2 integration

  • Note: Waiting for confirmation from WSO2.
  1. Support XMLbeans data binding for Axis2 Web services - 196954
  2. Support import and export of AAR (Axis2 Archives) - 168937 168938

Committed

Design for Extensibility

  1. Make the import of Web service Ant task file template extensible for different Web service runtime - 146023

Ease of Use

  1. Ant task should be more robust and give more meaningful error messages - 171705

Done

React to platform changes

  1. M2 - Migrate the Web Services Explorer from Eclipse Tomcat to Equinox Jetty - 192785

Design for Extensibility

  1. M3 - Make the profile compliance and validation page extensible - 196997
  2. M4 - Enhancing service policy framework and UI - 209858
  3. M4 - Allow extender to veto project/EAR - 203826
  4. M5 - EJB object selection in Web service wizard should support Java EE5 - 208795

Ease of Use

  1. M5 - Enable Web service scenarios on projects with stub targets when deployed on remote servers - 170141

Deferred

  1. Upgrading wsdl4j to 1.5.1 or later version - 197197
  2. Make the Web Services Explorer UI extensible - 197001
  3. Improve usability of the Web Services Explorer - 172266
  4. Shows the quality of service in effect for Web services wizard - 196999
  5. Smarter project switching when Web service type is changed - 194039
  6. Fine tune Web service creation extension point to factor in Web service runtime and server - 196966
  7. Enable extender specific EAR project naming - 171057
  8. Extension to allow custom configuration of available step - 170917
  9. Support hot deployment and hot update of Axis2 Web services - 168939
  10. Enable the Web services finder to find Axis2 Web service in it's own category - 196949
  11. Plug Axis2 generated JUnits into the Web services test framework - 196952
  12. 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.

Committed

Deferred

Release Engineering

Proposed

  • Need to sign jars for Ganymede release. (bug 216298)
  • Build individual source bundles (bug 132094)
  • Improve download pages and system (bug 197910)
    • Move PHP off download server.
    • Use Phoenix look and feel for download pages.
    • Divide build, tests, reports, etc, into smaller units, corresponding to projects (but also maintain Java and non-Java divisions).
    • Provide some means to download smaller units of WTP, possibly such as XML only, Common features, such as snippets view, facets framework.


Committed

  • Avoid use of download server for continuous builds. (Done in M5 development period)


Deferred


Back to WTP Requirements Main

Back to the top