| <?xml version="1.0" encoding="UTF-8"?> |
| <!DOCTYPE html |
| PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" |
| "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
| <html xmlns="http://www.w3.org/1999/xhtml"> |
| <head> |
| <meta |
| http-equiv="Content-Type" |
| content="text/html; charset=windows-1252" /> |
| <title>Eclipse Web Tools Project DRAFT 1.5 Plan</title> |
| </head> |
| <body> |
| <h1>Eclipse Web Tools Project DRAFT 1.5 Plan</h1> |
| <p><b>Initial draft</b> September 8, 2005 (by Jochen Krause / WTP Requirements Group based on WTP Project 1.0 Plan |
| and Eclipse Project DRAFT 3.2 Plan)</p> |
| <p><i> Please send comments about this <b>draft plan</b> to the </i>wtp-requirements@eclipse.org <i>mailing |
| list.</i></p> |
| <p>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.</p> |
| <p>Web Tools 1.5 will be compatible with Eclipse 3.2 Releases.</p> |
| <p>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.</p> |
| <p>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. </p> |
| <p>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.</p> |
| <p>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.</p> |
| <p>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.</p> |
| <p> </p> |
| <p>The current status of each plan item is noted:</p> |
| <p><b>High Priority</b> plan item - A high priority plan item is one that we have decided to address for the release |
| (committed).</p> |
| <p><b>Medium Priority</b> 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.</p> |
| <p><b>Low Priority </b>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</p> |
| <p><b>Deferred</b> 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.</p> |
| <h2>Release deliverables</h2> |
| <p>The release deliverables have the same form as previous releases, namely:</p> |
| <ul> |
| <li>Source code release for Eclipse WTP Project, available as versions tagged "R1_0" in the Eclipse |
| WTP Project</li> |
| <li>CVS repository</li> |
| <li>Eclipse WTP runtime binary and SDK download with all Eclipse pre-reqs (downloadable).</li> |
| <li>Eclipse WTP runtime binary and SDK download (downloadable).</li> |
| </ul> |
| <h2>Release milestones</h2> |
| <p>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.</p> |
| <p>The milestones are:</p> |
| <ul> |
| <li>TBD</li> |
| </ul> |
| <h2>Target Operating Environments</h2> |
| <p>Eclipse WTP is built on the Eclipse platform itself.</p> |
| <p>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.</p> |
| <p>Eclipse WTP is tested and validated on the following reference platforms (this list is updated over the course of |
| the release cycle):</p> |
| <table |
| border="BORDER" |
| cellspacing="1" |
| cellpadding="2" |
| width="821"> |
| <tr> |
| <td |
| valign="middle" |
| colspan="4" |
| bgcolor="#cccccc"> |
| <p align="center"><b>Eclipse WTP Reference Platforms</b><font |
| face="Times New Roman" |
| color="#000080"> </font></p> |
| </td> |
| </tr> |
| <tr> |
| <td |
| width="24%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080"><b>Operating system</b></font></td> |
| <td |
| width="14%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080"><b>Processor architecture</b></font></td> |
| <td |
| width="10%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080"><b>Window system</b></font></td> |
| <td |
| width="52%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080"><b>Java Platform</b></font></td> |
| </tr> |
| <tr> |
| <td |
| width="24%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080">Microsoft Windows XP</font></td> |
| <td |
| width="14%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080">Intel x86</font></td> |
| <td |
| width="10%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080">Win32</font></td> |
| <td |
| width="52%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080">Sun ... TBD</font></td> |
| </tr> |
| <tr> |
| <td |
| width="24%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080">Microsoft Windows XP</font></td> |
| <td |
| width="14%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080">Intel x86</font></td> |
| <td |
| width="10%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080">Win32</font></td> |
| <td |
| width="52%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080">IBM ... TBD</font></td> |
| </tr> |
| <tr> |
| <td |
| width="24%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080">Red Hat Enterprise Linux ... TBD</font></td> |
| <td |
| width="14%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080">Intel x86</font></td> |
| <td |
| width="10%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080">GTK</font></td> |
| <td |
| width="52%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080">Sun ... TBD</font></td> |
| </tr> |
| <tr> |
| <td |
| width="24%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080">Red Hat Enterprise Linux ... TBD</font></td> |
| <td |
| width="14%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080">Intel x86</font></td> |
| <td |
| width="10%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080">GTK</font></td> |
| <td |
| width="52%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080">IBM ... TBD</font></td> |
| </tr> |
| <tr> |
| <td |
| width="24%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080">SuSE Linux ... TBD</font></td> |
| <td |
| width="14%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080">Intel x86</font></td> |
| <td |
| width="10%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080">GTK</font></td> |
| <td |
| width="52%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080">Sun ... TBD</font></td> |
| </tr> |
| <tr> |
| <td |
| width="24%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080">SuSE Linux ... TBD/font></font></td> |
| <td |
| width="14%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080">Intel x86</font></td> |
| <td |
| width="10%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080">GTK</font></td> |
| <td |
| width="52%" |
| valign="middle"><font |
| face="Times New Roman" |
| color="#000080">IBM ... TBD</font></td> |
| </tr> |
| </table> |
| <p>Although untested, Eclipse WTP should work fine on other OSes that support the same window system. See also <a |
| href="http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_1.html/lTargetOperatingEnvironments"> <u>Eclipse |
| Target Operating Environments</u></a></p> |
| <p>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.</p> |
| <p>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.</p> |
| <h3>Internationalization</h3> |
| <p>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.</p> |
| <h2>Compatibility with Other WTP Releases</h2> |
| <p>Project Compatibility:</p> |
| <ul> |
| <li>Full compatibility with 1.0 projects</li> |
| <li><b>TBD</b></li> |
| </ul> |
| <p>Eclipse WTP deliverables will be compatible with Eclipse 3.2. No special attention will give for being compatible |
| with previous Eclipse versions.</p> |
| <h2>Eclipse WTP Subprojects</h2> |
| <p>The Eclipse WTP consists of 2 subprojects. Each subproject is covered in its own section:</p> |
| <a href="http://eclipse.org/webtools/wst/index.html"> Web Standard Tools</a> |
| <a href="http://eclipse.org/webtools/jst/index.html"> J2EE Standard Tools</a> |
| <p>For 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.</p> |
| <p>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]</p> |
| <h2><span>Web Standard Tools subproject</span></h2> |
| <h3><span>Architectural harmonization</span></h3> |
| <ul type="disc"> |
| <li>DTP (data tools)</li> |
| <li>Moving generic components to platform (like the browser to 3.1)</li> |
| <li>TPTP Validation (elaborate correction framework part of validation), TCP/IP sniffer (tcp/ip monitor)</li> |
| <li>EJB3</li> |
| <li>Lipido (AXE Cocoon tooling)</li> |
| </ul> |
| <h3><span>Web Services Support</span></h3> |
| <ul type="disc"> |
| <li>Soap 1.2 Support</li> |
| <li>WSDL 2.0 Support</li> |
| <li>New WS-I profiles</li> |
| <li>WS Security</li> |
| <li>Axis 2.0 Support</li> |
| </ul> |
| <h2><span>J2EE Standard Tools</span></h2> |
| <h3><span>Architectural harmonization</span></h3> |
| <ul type="disc"> |
| <li>EJB3 Projects</li> |
| </ul> |
| <h3><span>J2EE 1.5 Support</span></h3> |
| <ul type="disc"> |
| <li>EJB3</li> |
| <li>JSR 175 (Metadata) Support</li> |
| <li>JSF Support</li> |
| </ul> |
| <h3><span>Web Services Support</span></h3> |
| <ul type="disc"> |
| <li>JSR 181 (Web Services)</li> |
| </ul> |
| <h3><span>Server Runtime</span></h3> |
| <ul type="disc"> |
| <li>JSR 88 Support, Advanced Server Support for one/multiple open source J2EE server</li> |
| <li>Support for incremental deploy</li> |
| </ul> |
| <br /> |
| <p>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:</p> |
| <h3>EJB3.0 Use cases proposed by Ivelin Ivanov (JBoss)</h3> |
| <br /> |
| <p></p> |
| <p>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</p> |
| <p>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.</p> |
| <p>b) The wizard should give the user an option to either<br /> |
| "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.</p> |
| <p>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.</p> |
| <p>d) The user should have the option to make the Session bean either Stateful, or Stateless.</p> |
| <p>e) There should be an option for generating either annotated POJOs (default) or XML descriptors for all bean |
| meta-data.</p> |
| <p>2) An EJB3 Project Nature Wizard and related Classpath Containers for automated EJB3 API code completion and |
| compilation</p> |
| <p>a) The EJB3 project nature wizard should have all the options and steps the standard Java project wizard does.</p> |
| <p>b) The wizard will create classpath containers for the generated project that will contain all the classes |
| necessary for compilation of EJB3 APIs</p> |
| <p>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.</p> |
| <p>a) when defining the EJB3 project there should be away to associate the project with a db-server in the DTP |
| project</p> |
| <p>b) Using the catalog/schema/table/column/etc information found in the DTP project<br /> |
| we should provide seamless content-assitance inside the related java annotations</p> |
| <p>Note: This will require support from the JDT to allow non-JDT plugins to provide content assistance on |
| annotations values.</p> |
| <p>4) Message Driven Bean wizards that provide stub methods for the MessageListener interface, and use server tools |
| to find JMS Topics / Queues.</p> |
| <p>a) Similar to the Session Bean wizard, but without remote/local interface generation.</p> |
| <p>b) User should have the option to either "implement MessageListener" explicity, or simply implement the |
| "onMessage" method without the container contract.</p> |
| <p>c) Possible integration point w/ Server Tools: Locate Active JMS Queues and Topics for this MDB to subscribe to. |
| </p> |
| <p>d) There should be an option for generating either annotated POJOs (default) or XML descriptors for all bean |
| meta-data.<br /> |
| <br /> |
| </p> |
| <h3>JSR 88 Use Cases proposed by Ivelin Ivanov (JBoss), edited by Jochen Krause</h3> |
| <p>1) A method to deploy a packaged j2ee application, war, ear, etc through the jsr-88 API.</p> |
| <p>a) Provide a packaged jsr-88 deployment action</p> |
| <p>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.</p> |
| <p>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)</p> |
| <p>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.<br /> |
| <br /> |
| </p> |
| <p>2) Find out about missing deployment descriptor items for an unpackaged j2ee application</p> |
| <p>a) Enable user to discover missing descriptor elements</p> |
| <p>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.</p> |
| <p>c) See Use Case 1 b) d)</p> |
| <p>d) If there are no missing required xpaths for deployment, the user shall be able to package and deploy</p> |
| </body> |
| </html> |
