Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[] Architected Feature definitions

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

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


Back to the top