In "quick assessments" such as this one, its easy to seem critical, and hard to write all the good and complimentary things I see in WTP, so I hope this general statement suffices. There are a lot of good things, tremendous progress has been made, and all teams are working very hard to provide good function and true platform quality code and APIs. Its hard to ask for more than that, but below are some items that could use more work before Release 1.0 (and this is just in my humble, off hand impressions, so I may have missed things, or may have misinterpreted some things). I intend these remarks only as constructive suggestions or questions to make WTP even better than it is.

Overall, We still have too many plugins.

• Many divisions still determined by "function" rather than component.
• Many divisions still determined by "team" or "site" rather than component.
• many appear to be used by only one other plugin, so why separate? (there's even one not pre-req'd by any plugin .. pure extension).
• Many "validation" ones are separate ... is there a reason for this? [AR] wsi command line validation is required. [DW] but does this require separate plugins?
• Many "annotation" ones are separate ... is there a reason for this?
• Some need to renamed to make obvious "core vs. ui"

• General agreement should be primarily from "end user point of view".
• Should be based on subsystems, as defined below.
• Still need to investigate model vs. UI packaging.

they are, first and foremost, 'internal', subject to change, even removal. there is no implied support. They have been named "provisional" as a signal that we'd like review comments and statements of need from community for future releases. All cases of 'internal' are so named so that clients who use them assume the risk of re-working their code in future versions. We would like it if when any internal package found to be needed, feature requests were opened so appropriate solutions could be designed to satisfy needs of community (and still provide platform quality APIs).

Note: in M4, much effort was made to assess what could be API, and what could not. In some cases, the "could not" cases did not get renamed in time for M4. Will do early in M5 cycle.

'Friend' meaning ok for some "outside" component to use, while still inside project. We could not meaningful do this for release 1. This is something we should do for future releases.

This is currently a fairly large "unknown" and we need improved reports (and component definitions from base Eclipse). I suspect we have a lot. I suspect some can be "cleaned up" and some can not (and will need more work with base to know if "future requirement" or if we are doing something wrong.)

For those items below marked "ready for review" I have opened bugzilla meta-bugs to encourage explicit comments from community and clients specifically during M5 cycle review. These reviews are not so much for feature requests (those could be seperate bugzillas) but for things like if JavaDoc is wrong or in adequeate, if something appears not to be evolvable, or even if the design or problem to solve seems unclear so that you could not write to the APIs. Or ... you could include a few compliments :)

Note: following "subsystem" don't match Arch. Doc. exactly (it needs to be updated), but concept is the same. Features, dependencies, etc., still flow from the subsystem definitions.

Common Subsystem/Feature

• Common Component
• Extensible Navigator --> internalProvisional, moving to base 3.2
• Tabbed Property View --> internalProvisional, moving to base 3.2
• Snippets View --> internalProvisional. Belongs here in WTP. Needs more work to better integrate with Eclipse Templates (if possible)
• Extensible URI Resolver --> internalProvisional.

Appears not to handle several use-cases, question is if it ever could. Some question on OASIS standards.

• common frameworks
• data operations - IDataModel - ready for review. 94889

[need review from Chris B., to see if he could move to it post release 1.0]

• data wizards - provisional
• Validation Framework Component --> internalProvisional.

good client design and requirements sessions, but may be trying to cover too much.

• Command Framework Component

I don't think should be a "component". (since we don't want to introduce yet another 'command' or 'operation' framework). I don't think it should have provisional API. Could it be integrated with "DataOperations"? There is fundamental question if "running headless eclipse application" suffices, or if we really need to provide an API that does not pre-req Eclipse at all.

• common.componentcore (needed for flexible projects) - Ready for Review 94890

But pure resource part rightfully belongs in base. Need better distinction between flexible project consumers, and Flexible project providers (those that define what the flexible project is). (former might be evolvable API, but not sure later could be without being in proper project). My advice is to publish as internal .provisional ... but don't mind pushing forward with review, since part of it belongs in base, since not sure if it works well with base's "logical resources". since providing team same as client team, since base is looking at "non-local resources" in 3.2 ... all of which could impact design. especially need review from base to determine if evolvable with their plans.

Server Subsystem/Feature

• Server Component -- Ready for Review 94891

some review already indicated some issues to resolve especially with server providers

• Internet Component
• browser/launch URL API --> moved to Eclipse 3.1.
• Pref. --> 3.2
• Monitor --> internal.provisional, pending post 1.0 review with TPTP

Database Subsystem/Feature

• DB/SQL - internal, not API due to probable DTP project merge

XML Subsystem/Feature

• XML Component - some internal provisional .. need better design documents .. more refactoring
• Schema Component - some internal provisional .. need better design documents .. more refactoring
• DTD Component some minimal internal provisional .. need better design documents .. more refactoring
• SSE Component some internal provisional .. need better design documents ... .. more refactoring, especially need better distinction between language consumer APIs and language provider APIs.

Web Services Subsystem/Feature

• WS Component ... some internal provisional
• WSDL Component. Ready For Review 94892 . WSDL Spec Model API (see "EMF Models" notes).
• WSI Component ... ? some API (provisional?) from WSTV project ?

Web Resources Subsystem/Feature

• HTML Component .. some internal provisional .. need better design documents
• CSS Component ... some internal provisional .. need better design documents
• JavaScript Component some minimal internal provisional .. need better design documents
• Web Project Component - no api, HTML Web Project

JST Server Subsystem/Feature

• Server Component - Ready For Review 94893

J2EE Web Subsystem/Feature (WAR)

• J2EE Core Web Model Component [Issue: not currently packaged this way] Ready For Review 94887 (see "EMF Models" notes).
• Servlet Component/J2EEWebProject ... some API, create web component API
• JSP Component ... some internal provisional .. need better design documents
• WS Web Component (JAXRPC)

J2EE Enterprise Subsystem/Feature (EARs, EJBJar, EJBClientJar, RARs)

• J2EE Core Enterprise Model Component [Issue: not currently packaged this way] Ready For Review 94887 (see "EMF Models" notes).
• EJB Component
• WS Component

Note: EMF Models for J2EE and WSDL have expressed the primary API part of their models is intended to be the interfaces defined by respective specifications. But general consensus in 5/3 review meeting that its "ok to assume EMF model" is part of the API. Still, components encouraged to "spec" how generated, intended use, etc.