|WTP Architectural Assessment at M4|
Preliminary Architectural Assessment
|General impressions of status|
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.
|State of plugin structure|
Overall, We still have too many plugins.
|Need more granular feature definitions (both for end users, and products building on WTP that may not use all of WTP).|
|Need to define and set proper expectation and definition of "internal.provisional".|
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.
|We have no "friend" APIs defined for WTP.|
'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.
|API violations in our use of base Eclipse and pre-reqs?|
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.)
|Summary of components and API status|
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.
Appears not to handle several use-cases, question is if it ever could. Some question on OASIS standards.
[need review from Chris B., to see if he could move to it post release 1.0]
good client design and requirements sessions, but may be trying to cover too much.
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.
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.
some review already indicated some issues to resolve especially with server providers
Web Services Subsystem/Feature
Web Resources Subsystem/Feature
JST Server Subsystem/Feature
J2EE Web Subsystem/Feature (WAR)
J2EE Enterprise Subsystem/Feature (EARs, EJBJar, EJBClientJar, RARs)
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.