[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[wtp-dev] a new WTP Architecture Overview document is available
|
I've started a new WTP Architecture Overview document,
temporarily available in CVS as indicated below.
(After some initial "sanity check" review,
I'll move to website location, and delete old one based on initial contribution).
http://dev.eclipse.org/viewcvs/indexwebtools.cgi/%7Echeckout%7E/wtp-jst-home/WTPArchAndDesignDocs/WebContent/arch_and_design/ComponentsBySubsystem.html
It's basically the "component view" from
the previous document. (This one, though, is truly architectural, it describes
where we want to end up ... it does not describe the
existing structure, which needs much refactoring and holes filled in).
In this version, I have done much more to group some
components into "subsystems".
I think these subsystems will be important for the
following reasons:
1. it gives some
conceptual simplification, not to be under estimated (we have 11 subsystems,
23 components, and
still too
many individual plugins to be easily understood).
2. I think its
easier to describe dependancies at a sub-system level, instead of component
by component.
3. Most important,
for most readers, will be that I think the subsystems can form the building
blocks
of our top-most "PDE features" ... some
of which would be available via update manager. In fact,
in that overview, I've proposed 3 subsystems be made
available via update manager, in addition to JST and
WST, that is. Namely, XML Subsystem (which includes
schema and dtd components), JSP Web Resources (JSP editing/model, with
all
dependancies, e.g. HTML, CSS, _javascript_), and lastly,
the "Database Subsystem" (RDB and SQL).
I picked these three because these are the only three
I've heard from both users and other projects as being
important to be available separately from WST and
JST.
I'm sure other projects and some users will want
more fine-grained pieces ... but I propose that if they do, they would
have to download larger piece and then pick out what
they want. (There's always limits and trade-offs
to be made with the divisions ... I've tried to reach
a meaningful, but manageable balance). Again, this is a proposal,
please let me know if I've overlooked other requirements
or have been too accommodating. In summary, this would be
5 updated manager features, each with "runtime"
and "SDK" flavors, for 10 total ... I hope no one wants more!]
[BTW, I also propose we not worry about any accurate
sub-feature definition
for WTP M2 ... that we wait until the WTP M3 cycle
to even begin defining those in the repository].
Please review overview for accuracy and completeness.
I am due to present/review this to EMO
Architecture Council on 12/2, so ... sorry I haven't
allowed more time for review.
Ideas and feedback more than welcome, as always.