Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Are we there yet?

Hi Team,

Following up on the install scenarios.  A wiki page has been created to document the install scenario results.  Please take a few minutes to run these scenarios and update your results.  Thank you!

We're still missing smoktest results from a couple of teams on the final Ganymede driver (JPA & JSDT), if you could take a minutes to update.  Thanks!


Helen Zhang PMPĀ®
Rational Architecture Management Project Management Office
Eclipse Webtools Platform (WTP)

IBM Toronto Software Lab | 8200 Warden Ave. | Markham | L6G 1C7
Email: hjzhang@xxxxxxxxxx | Phone: 905-413-3443 | T/L: 969-3443

David M Williams <david_williams@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

06/16/2008 12:20 AM

Please respond to
"General discussion of project-wide or architectural issues."        <wtp-dev@xxxxxxxxxxx>

[wtp-dev] Are we there yet?

Imagine a family on a long, hot summer vacation, with a car full of kids, ... I feel like that father :)
And, the answer is the same ... "no, we are not there yet, but just a little further ... so you can hold it! "  (as my father used to say :)

But honest, we really are close. Off hand I can think of a few things yet to do ... I'm sure Helen will be reminding us of any others.

1. Verify Bugs.
Remember to verify "resolved" bugs, especially those that were opened as blockers and criticals! Preferably all 'majors' too ... but I personally am not too worried about 'normal' ones (they should be verified, of course, but I just mean if you have to prioritize, those would be pretty low on the to-do list).

If you forget what it means to verify a 'dup' bug, and similar, please see
If it is not obvious, we are at the point that we can not always wait for the originator to 'verify' a bug ... so team leads should themselves (at least for the blocking/critical ones!).

2. Triage Bugs.
Please make sure all your open critical and blocking defects are properly triaged: If you can't reproduce it, resolve it as works for me, but if you can confirm it as a bug, and you agree it deserves a blocking or critical status, then please explain why it can not be fixed right now (before release) and what our plan is to address it (either to provide patch, or fix in 3.0.1).

The PMC will be asked to take a close look at our blocking and critical list, on Tuesday, to confirm we all agree we are ready to release, even with these blockers and criticals.

3. Confirm Installs.
Please confirm and test all the different install methods we now have. Perhaps Helen ... or someone ... can think of an easy way to be systematic and document what's been tested? I don't intend each team to test all possibilities. Some teams have a more "vested interest" in some install paths. And, by "testing" I don't mean to necessarily do a full test .... but, install it, inspect plugins, features, (and documentation, preferences, help, etc.) and be sure what you would expect to be there, really is there, and sanity check a couple of "main path" tasks.

A. JEE Developer IDE.

Currently, the URL to get the most recent JEE package from is
but you might check
to be sure you are getting the most recent. (if anything is more recent that 20080615).

On Tuesday, the "most recent" URL will be
Which is likely to be the final version,
to be moved to official release URL, on the release date.

This is "the fullest" install ... should have everything that is in our zips, plus Mylin, plus remote target management. It won't have 'capabilities', that is a known bug (235089) but you might check other preference pages, etc. Also note: this is a an "end-user" package, so should be not have source nor JavaDoc.
This package is the most popular download package from Eclipse, so it's important we verify it.
Windows, and Linux 32 are pretty easy .. and Nick often checks the Mac for us, since he's the only Mac user in the group ... that I know of.
Anyone have a 64 bit system they can verify that install on?

B. Update sites
... for now, you'll have to add these locations to your sites for software updates ... only after release, will the built-in URLs point to the right places.

B1. Ganymede update site

For now, the best URL to use is
(I'm not sure what the exact plan is, but at some point, what is at staging is moved to
and that will become the official released version

Using Ganymede update site, you can start with _only_ the Eclipse Platform, and pick individual features to install. What ever our features need, should be pulled down automatically (no "select required" any longer).

Main install scenarios

_javascript_ (only 'platform' is required).

XML (platform, gef, a few emf pieces and xsd info-set are all required ... that is, should also end up in your install).
Web Developer (as above ... i.e. still no JDT!).
JEE Developer (requires JDT, and some features from DTP).

Secondary install scenarios

There are some "optional" features you can pick (unfortunately, this release, most of these 'optional' features are also installed if you install the JEE Developer ... a change in behavior from update manager was discovered too late to change our feature definitions). But, if you start off picking an optional feature, it should pull in anything required.

B2. Webtools update site

Similar to Ganymede site, but all pre-reqs must be installed already.
The URL for now is

The main scenario to test here ... the one we have designed for ... is that if someone
installed some webtools stuff from Ganymede, then you can go to the Webtools update site to get the matching SDK portion, for those users that need the source and JavaDoc.

(Eventually, the XSL Incubating feature will be here too ... but, haven't update for that yet).

Note: for those of you that haven't seen it yet, the current UI for Software Updates has one very different behavior than the old UM UI. (This is documented as an issue in bug 224472) If you install something like "Web Developer" which also includes XML and _javascript_, the included features stay on the "available software" list, as though it was not installed (even though it was). The reason for this is to "match" exactly what the user choose to install, not what was done "under the covers"). I think ... though I haven't tested it myself ... is that this allows for improved uninstall behavior (or, at least will in the future). So certainly open bugs if you find them, or see things you don't like ... but, this final exercise isn't to test or evaluate "Software Updates" UI .. it's just to make sure things work with respect to Webtools installations.

Thanks everyone ... just a little further.

wtp-dev mailing list

Back to the top