Initial draft September 8, 2005 (by Jochen Krause / WTP Requirements Group based on WTP Project 1.0 Plan and Eclipse Project DRAFT 3.2 Plan)
Please send comments about this draft plan to the wtp-requirements@eclipse.org mailing list.
This document lays out the feature and API set for the next feature release of Eclipse Web Tools after 1.0, designated release 1.5. This document is a draft and is subject to change, we welcome all feedback.
Web Tools 1.5 will be compatible with Eclipse 3.2 Releases.
Plans do not materialize out of nowhere, nor are they entirely static. 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 two subprojects under the Eclipse Web Tools top-level project. 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.
Not all plan items represent the same amount of work; some may be quite large, others, quite small. Some plan items may involve work that is localized to a single Platform component; others may involve coordinated changes to several components; other may pervade the entire Platform. Although some plan items are for work that is more pressing that others, the plan items appear in no particular order.
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.
The release deliverables have the same form as previous releases, namely:
Release milestone occurring at roughly 6 week intervals in synchronisation with the Eclipse Platform milestone releases (starting early 2006 latest) and will be compatible with Eclipse 3.2 releases.
The milestones are:
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 1.0 release of the Eclipse WTP Project is written and compiled against version 1.4 of the Java 2 Platform APIs, and targeted to run on version 1.4 and 5.0 (1.5) of the Java 2 Runtime Environment, Standard Edition.
Eclipse WTP is tested and validated on the following reference platforms (this list is updated over the course of the release cycle):
|
Eclipse WTP Reference Platforms |
|||
| Operating system | Processor architecture | Window system | Java Platform |
| Microsoft Windows XP | Intel x86 | Win32 | Sun ... TBD |
| Microsoft Windows XP | Intel x86 | Win32 | IBM ... TBD |
| Red Hat Enterprise Linux ... TBD | Intel x86 | GTK | Sun ... TBD |
| Red Hat Enterprise Linux ... TBD | Intel x86 | GTK | IBM ... TBD |
| SuSE Linux ... TBD | Intel x86 | GTK | Sun ... TBD |
| SuSE Linux ... TBD/font> | Intel x86 | GTK | IBM ... TBD |
Although untested, Eclipse WTP should work fine on other OSes that support the same window system. See also Eclipse Target Operating Environments
Eclipse WTP is planned to support models for projects, editors, web and J2EE artefacts, servers. Whereas Eclipse WTP would not add OS dependencies to support the first three, projects, editors and artefacts, integrating servers to Eclipse WTP would imply some OS dependencies. Eclipse WTP is targeted to be OS independent through a modular conception. So, components for servers integration will be available out of Eclipse WTP Web, or J2EE, Standard Tools runtime binary distributions.
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.
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.
Project Compatibility:
Eclipse WTP deliverables will be compatible with Eclipse 3.2. No special attention will give for being compatible with previous Eclipse versions.
The Eclipse WTP consists of 2 subprojects. Each subproject is covered in its own section:
Web Standard Tools J2EE Standard ToolsFor each subproject, the 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]
The following shall serve as an example how the community can help to provide input for their desired use cases, this details the EJB 3.0 support of our top level item J2EE 1.5 Support:
1) Wizards for Stateless and Stateful Session Beans that follow J2EE naming conventions and generate both the bean implementation class and the remote / local (or both) interfaces
a) The user will be able to invoke the Session bean wizard through the File > New > Other.. menu of eclipse. If the user has right clicked on any package or source directory, the wizard should auto-fill the pertinent information.
b) The wizard should give the user an option to either
"Follow J2EE Naming Standards", and enter a simple bean name, or to "Customize Type Names", and
manually enter the bean implementation class, and remote and/or local interfaces.
c) The user should have the ability to generate Local, and Remote interfaces for the bean. It is not required to generate either. The generated bean implementation class should implement all generated business interfaces.
d) The user should have the option to make the Session bean either Stateful, or Stateless.
e) There should be an option for generating either annotated POJOs (default) or XML descriptors for all bean meta-data.
2) An EJB3 Project Nature Wizard and related Classpath Containers for automated EJB3 API code completion and compilation
a) The EJB3 project nature wizard should have all the options and steps the standard Java project wizard does.
b) The wizard will create classpath containers for the generated project that will contain all the classes necessary for compilation of EJB3 APIs
3) Table and column meta-data completion for common entity annotations such as @Table, @Column, @JoinColumn, and @Id. This could be a possible integration point with the Data Tools Project.
a) when defining the EJB3 project there should be away to associate the project with a db-server in the DTP project
b) Using the catalog/schema/table/column/etc information found in the DTP project
we should provide seamless content-assitance inside the related java annotations
Note: This will require support from the JDT to allow non-JDT plugins to provide content assistance on annotations values.
4) Message Driven Bean wizards that provide stub methods for the MessageListener interface, and use server tools to find JMS Topics / Queues.
a) Similar to the Session Bean wizard, but without remote/local interface generation.
b) User should have the option to either "implement MessageListener" explicity, or simply implement the "onMessage" method without the container contract.
c) Possible integration point w/ Server Tools: Locate Active JMS Queues and Topics for this MDB to subscribe to.
d) There should be an option for generating either annotated POJOs (default) or XML descriptors for all bean
meta-data.
1) A method to deploy a packaged j2ee application, war, ear, etc through the jsr-88 API.
a) Provide a packaged jsr-88 deployment action
b) If the deployable package's descriptors all match the requirements, the user should be able to select a target from those listed in preferences and deployment should begin.
c) If the deployable package is missing information, the missing information should be matched with the unpackaged descriptor and the user should be able to fill in missing data( e.g. with a tabbed dialog, with different tabs for each descriptor that is missing elements)
d) The user shall be able to manually add missing information on the fly, rather than through the above mentioned
method. It should be possible to persist the information that was added on the fly to the appropriate descriptor file.
2) Find out about missing deployment descriptor items for an unpackaged j2ee application
a) Enable user to discover missing descriptor elements
b) If the project has an associated packaging configuration (project preferences), the tool will generate the model using the packaging configuration as a guide. Otherwise it will suggest / redirect to the packaging configuration preference page.
c) See Use Case 1 b) – d)
d) If there are no missing required xpaths for deployment, the user shall be able to package and deploy