[wtp-dev] Review Requested: Proposed (updated) feature/component definit

[David M Williams <david_williams@xxxxxxxxxx>]

I have been working an a document to update our "feature
level
component" definitions and relationships. (Its
hard to find the right
term ... please read document, and suggest improvements,
if needed  :)

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

I'd like to propose we actual start building things
in the way
described in that document. This will be important
to "do the right
way" in order to allow

        1. Eclipse Members who
extend or "repackage" WTP to  coexist in
        a users installed environment.
(without having to "hack" the
        core deliverables).

        2. The documentation to
be correctly partitioned for
        "repackaging".

        3. the sdk and tests portions
of WTP to be meaningful even in
        different configurations.

Oh, and it also enforces good practices on having
clear well documented
dependancies, such as between "UI" and "model"
level function, for
example.

There's only a few "new ideas" in the document,
the rest are just fine tuning and getting specific about
what's already been documented and started pre 0.7
(but not finished due to time/resource constraints).

One thing that's not new is the core vs. UI distinction
... I (and
others) opened bugs on some obvious errors in some
areas of our design
... so ... time to fix those. I'd like to propose
we actually "enforce"
this in our builds so model-level code can be built
(in theory) without
the UI pieces.  (I say in theory, because I'm
 not suggesting we
actually "deliver" that way, or anything.)

There are two new things in the document that need
committer,
community, and adapter review:

1. One critical, I believe, but a new way of thinking
for us in WTP. We
need a better division for our "product adapters".
As the recent note to
this list about the Geronimo Server Adapter implied,
the source of our
product adapters will be a continually changing story
(both literally as
to the source location of the adapter, but also indirectly
based on the
packaging decisions of WTP adapters) so we need to
"wall off" those
adapters so the core features do not have to be repackage
to accommodate
those changes. This is the sort of change that is
not needed for our WTP
needs per se, but is needed for us to be a "good
citizen" in the whole
Eclipse community of add-on adapters and extenders.

2. Less critical, but also a new way of thinking  ...
I'd like to
propose our JUnit tests be packaged along with the
rest of the SDK
builds. I think this simplifies our "download
pages" but more
importantly, I'd like to better foster the idea that
anyone doing "SDK
level work" should always have the tests that
go with that version of
the SDK. Not only does this encourage them to run
the tests often as
they consider code changes or submitted patches, but
some would say that
ideally the JUnit tests are part of the "spec"
of some function or
API's. I'll be evaluating the increase in download
size, but would hope
that would not be an inhibitor.

So ... take a look, feel free to comment. I've opened
the following
enhancement request so we can capture any discussion
or decisions in one
place:

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

Oh, and BTW, Naci is working on related document for
our build
requirements and process, and while we have compared
notes, and seen
earlier drafts of each others document, I'm sure we'll
have some
coordination to do once both are documented ... I
am hoping his is
clearly in the "how" portion of what we
do, mine is intended to
be in the "what" portion.