Note that we are trying to make very
1) where the "model"
vs. "ui" lines are
2) where exactly the dependancies
are between our own "component features" and for "external
(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) --
overlook component of
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
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
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