development/requirements/wtp_1_5_plan.html - www.eclipse.org/webtools - Git at Google

 <html>

 <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 &amp; 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.&nbsp; </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>&nbsp;</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 &quot;R1_0&quot; 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 &quot;pure&quot; 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 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></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></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>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 &gt;
 New &gt; 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>
 &quot;Follow J2EE Naming Standards&quot;, and enter a simple bean name, or to &quot;Customize
 Type Names&quot;, 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 &quot;implement MessageListener&quot;
 explicity, or simply implement the &quot;onMessage&quot; 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>
	<html>

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