Re: [wtp-dev] WTP 1.0 M4 Shutdown Schedule

[Chris Brealey <cbrealey@xxxxxxxxxx>]

Arthur et al.,
in response, here's the current state
of affairs with the Web services components for M4:

1. APIs

Our emphasis for M4 has been on the
design of a new provisional API that the community can begin using to extend
the Web services platform. The primary reason we have made this API provisional
instead of public is that our own plugins for Apache Axis represent the
only known extensions to this API. Without at least one or two additional,
significant third-party extensions to the platform to help validate its
design, identify flaws, etc., it would be quite premature to lock in a
public API. I would encourage, request, (and even get down on all fours
and beg!) anyone in the community who is thinking of adding Web services
runtime support to our Web services tools platform to pick up M4 and review,
and help us evolve, our provisional API to a point that we can consider
it well validated and ready for public prime time in WTP 1.1.

I will ensure all API we intend to make
public in WTP 1.1 is appropriately packaged as "internal.provisional"
in M4.

Because of our focus on the provisional
API, the implementation and functionality of Web services in M4 will not
be as stable as it was in M3. M5 truely represents the implementation milestone
where stability will be restored and some functional improvements added
in. The current outlook is that our major scenarios will continue to function
in M4, but - to be blunt - the path to April 22 will be a squeaker, and
workarounds will be required (though nothing too hairy, we think).

2. Test Plans 

We will have our test plans with anticipated workarounds documented by
end of day Friday.

3. EMF, GEF, and JEM Prerequisites 

Any idea when these will be available (wrt. to our April 22 M4 date)?

4. Bugzilla Bugs

Will do, but as I mentioned above, it
will be tight. We are chipping away at bugs in the implementation behind
our new provisional API and the Apache Axis extensions to it, one by one,
and are making good progress. We also have some defects against the J2EE
component particularly where we have to integrate with the new flexible
project stuff, and are getting really good support from them (with thanks!).

5. Third Party Content 

"Speaking" for the component most impacted by this, thank you.
We've been waiting for approval for too long now.

6. Ship Readiness Polls 

It is unlikely we will be able to commence
testing until at least Thursday of next week. The Web services code in
this week's integration build will not be functional enough to do more
than a sniff test. Again, our outlook is that we'll have a happier component
for next week's build, but usually the integration builds don't settle
down until the third day in the cycle (Thursday). I won't be able to hazard
a vote any earlier than Friday.


Cheers - CB.

Chris Brealey
Rational Studio Java Web Services, IBM Canada Ltd.
D3-275, D3/ENX/8200/MKM, 8200 Warden Avenue, Markham, Ontario, Canada,
L6G 1C7
cbrealey@xxxxxxxxxx, 905.413.6038, tieline:969.6038, fax:905.413.4920

Arthur Ryman/Toronto/IBM@IBMCA
Sent by: wtp-dev-bounces@xxxxxxxxxxx

04/12/2005 03:17 PM

Please respond to
"General discussion of project-wide or architectural issues."

To	wtp-dev@xxxxxxxxxxx
cc
Subject	[wtp-dev] WTP 1.0 M4 Shutdown Schedule

Our target release date is 2005-04-22. This note summarizes the key actions
that are required for us to meet that date. 

1. APIs 

There has been great progress in API definition, especially in the completion
of Javadoc. However, some components have not stablised their definitions,
or do not have adequate JUnit coverage. We therefore must defer those APIs
to WTP 1.1. This action will ensure that the APIs that we do release in
WTP 1.0 are built to last. The work that has been done on the deferred
APIs will put us in a great position to complete the APIs in WTP 1.1. The
extra time will also let us get extremely valuable feedback from products
that plan to use the APIs. 

Therefore, all component owners should rename their deferred APIs to "internal.provisional"
asap this week. Our goal should be to enter next week with code that is
as close as possible to the final M4 code so that we can focus on defect
resolution. 

2. Test Plans 

All component test plans should be updated by the end of this week, 2005-04-15.
This will let us enter our test pass next week. 

3. EMF, GEF, and JEM Prerequisites 

At present we are using I-builds for EMF, GEF, and JEM. We should not release
WTP milestones based on I-builds of other components. We should cut over
to milestone builds as soon as they become available (probably Thursday
for EMF and GEF, and shortly after that for JEM) so that our test results
are valid. 

4. Bugzilla Bugs 

All component leads should review their defect queues and should resolve
all stop-ship problems next week. 

5. Third Party Content 

We may obtain legal approval from the Eclipse Foundation to redistribute
some 3PC by the end of this week. If we receive approval in time, we should
incorporate the 3PC into our build to simplify the installation process
for users. 

6. Ship Readiness Polls 

Next week component leads should be prepared to respond to polls with go/no-go
votes based on their test results and defect status. Any no-go vote will
have to be resolved prior to us releasing M4. 

Arthur Ryman,
Rational Desktop Tools Development

phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@xxxxxxx
intranet: http://labweb.torolab.ibm.com/DRY6/_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev