[eclipse.org-architecture-council] Architected Feature definitions

[David M Williams <david_williams@xxxxxxxxxx>]

Done! in three minutes! ... well, plus
the 3 weeks I've been spending prior to the meeting :) 


You can see the direction we are headed
with our "component feature" dependancy diagrams at 

http://www.eclipse.org/webtools/development/arch_and_design/subsystems/SubsystemsAndFeatures.html

Note that we are trying to make very
clear
1)  where the "model"
vs. "ui" lines are 
2)  where exactly the dependancies
are between our own "component features" and for "external
features" 
    (e.g. GEF and EMF and
JDT and "third party" code). 
3) how the "docs" fit in (both
for "dynamic help", and "info center" type help) --
a frequently 
    overlook component of
architecture :) 
4) and how those dependancies "build"
on one another to "roll-up" to final deliverables. 

We in WTP have LOTS of plugins, and
plugin diagrams would be too complicated
to easily visualize, but their dependancies
would be "sound" if they live within the bounds 
defined by these component-feature dependancies.

[We should estimate number of plugins
in the as-yet-unnamed "Eclipse Train"! ]

We call these "component features"
or "build component features" to help set them apart from the
type 
of features that end users see, can
optionally install via update manager, etc. 

So, what do you think ... helpful? Redundant?
Not "boxy" enough? :) 

In all seriousness, feedback would be
greatly welcome, either how to have better "architecture document"

in general, or any specifics about WTP's
architecture. 

Oh, and note the diagrams truly are
an "architecture" ... we still violate it in a few places, but
it describes the direction 
we are headed

David