Re: [wtp-dev] a new WTP Architecture Overview document is available

[Chuck Bridgham <cbridgha@xxxxxxxxxx>]

Also we may have some "JEM"
dependencies in wst right now,   we are currently working to break
these dependecies and refactor before the M2 release.  So the "vision"
in the presentation still makes sense.

Thanks - Chuck

Rational J2EE Tooling Team Lead
IBM Software Lab - Research Triangle Park, NC
Email:  cbridgha@xxxxxxxxxx
Phone: 919-254-1848 (T/L: 444)

Lawrence Mandel <lmandel@xxxxxxxxxx>
Sent by: wtp-dev-admin@xxxxxxxxxxx

11/22/2004 10:08 AM

Please respond to
wtp-dev

To	wtp-dev@xxxxxxxxxxx
cc
Subject	Re: [wtp-dev] a new WTP Architecture Overview document is available

Hi David, 

"JDT. Not required by WST, but required by JST.
Note: we don't rule out that we might require it someday in WST ... but
no known cases currently."

The validation framework currently requires JDT although there's been talk
about removing this dependency. Just thought you should be aware of this
for your presentation. 

Lawrence Mandel

Software Developer
IBM Rational Software - XML Web Services Tooling
Phone: 905 - 413 - 3814   Fax: 905 - 413 - 4920
lmandel@xxxxxxxxxx

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

11/22/2004 04:32 AM

Please respond to
wtp-dev

To	wtp-dev@xxxxxxxxxxx
cc
Subject	[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.