The wst.internet, wst.server, and jst.server
milestone plans are in place for M3 and on target for completion in early
February. API definition is still a high priority across the board, and
we've marked the items we're already working on.
Since we have relatively few committers
across this area, I'd like to encourage the community to get involved.
We can really use help in the following areas:
Providing fixes or minor enhancements
to the server framework, Web browser, or Tomcat support
API cleanliness and review
Writing JUnit tests
WebSphere Tools - IBM Canada Ltd.
(905) 413-3503 (tieline 969)
Arthur Ryman/Toronto/IBM@IBMCA Sent by: wtp-dev-admin@xxxxxxxxxxx
01/11/2005 10:29 AM
Please respond to
[wtp-dev] Milestone Plan
Completion Action Items - Status Requested
Would all component leads please carefully review this note and reply to
it with your status. All component leads should complete their milestone
plans asap, ideally by the end of this week. Please report the current
status of your milestone plan and the target completion date.
We need to finalize our milestone plans for the remainder of the 1.0 release.
Our plan is to have milestone releases every 8 weeks, and then release
WTP 1.0 shorty after Eclipse 3.1 GA. Our milestones will be based
on Eclipse 3.1 milestones  Here's our draft schedule:
2/25 WTP 1.0 M3 based on Eclipse 3.1 M5 (2/18)
4/22 WTP 1.0 M4 based on Eclipse 3.1 M6 (4/1) - API Freeze
6/17 WTP 1.0 M5 based on Eclipse 3.1 M7 (5/13)
7/29 WTP 1.0 GA based on Eclipse 3.1 GA (6/25)
Please write your plans using the XML format created by Craig Salter. Follow
Craig's XSD component example . The purpose of the XML format is to
1) give all plans a common look and feel, and 2) to allow us to automatically
aggregate all the component plans into a master summary plan (with links
back to the component plans).
If you are not comfortable with XML, use HTML for now and convert it later.
Don't let moving to the XML format delay the completion of your plans.
Note that I have marked M4 as our API freeze milestone. API definition
is a high priority item and should be included in your milestone plans.
Within each component you should only define API where you know it is required.
Our goal is to provide a stable API so any API you define now must be preserved
in future releases. You can always add API in future releases, so be conservative
Jeffrey Liu has added the currently available Eclipse "internal"
tool to our build process. See M2 for an example of the output . You
can use the output to help you identlfy users of your components.
The output from this tool does not reflect the concept of a component.
It works at the plug-in level, not the component level. A component is
a collection of plug-ins (and plug-in fragments). It is OK to use internal
packages across plug-ins within a component. We are working with Jim des
Rivières (aka Jeem) to upgrade the API scanning tool. We are going
to precisely define the concept of a component (i.e. we'll define a component.xml
file that is analogous to the plugin,xml file). This will eliminate a lot
of the false positives from the tool.