I'll echo what others have said in that
this looks like a good design with worrisome timing, particularly for the
Web services component, since much of it sits on top of the J2EE and Server
components. Here is a brief summary of the impact and related concerns:
Web service tools make extensive use of
the API related to IRuntime and IRuntimeType for defaulting and validation
of component and server/server type selection in the Web service/client
wizards/pop-up actions. We're currently using these API to do things like:
1. given a component, get a list of
valid server types that component could be associated with
2. given a server/server type, determine
whether is supports a particular J2EE version
3. given a server/server type, determine
if it supports EAR association.
With the removal of the runtime target API,
as we know it today, we would require new utilities to help us answer us
these (and related) questions using features.
The webserviceRuntime extension point, which
is at the heart of the wizard framework, would have to be revamped in order
to identify module types and version numbers using features. Even if we
left the extension XML the same, the code that reads/interprets it would
still have to made feature-aware in order to make use of feature based
utilities and APIs.
Also, Web service tools would be affected
by any modifications to the mechanisms used to programmatically create
flexible projects and components within them. I guess it's not clear to
me from the proposed design how or if existing operations like WebComponentCreationOperation,
etc. will be affected.
The main concern lies with timing. The J2EE
and Server component work for supporting features needs to be mostly complete
and relatively stable before Web services work can begin, which, depending
on the final dates, could leave us with very little time, adding to the
risk of quality and stability problems in this component in M5.
IBM Rational Software