John,
I am glad you are bringing these questions
up.
Use cases 1 and 2 can be solved with the
existing infrastructure. They are including in the list to make sure that the
new design does not break them.
Use cases 3-5 cannot be solved with what
we currently have and this is what we are trying to accomplish with this
proposal.
3. Create a component with a carefully
chosen set of features enabled. I have a particular architectural model in
mind. For example, I know that this web module will be used to implement a
webservice, and should not contain UI.
Forcing a user upfront to know what features they
want ahead of time, seems like a very intimidating out of the box experience.
This use case is not for
the user who would feel intimidated by all the choices. Such a user would
choose either 1 or 2. This is intended for someone who is extremely
knowledgeable and knows exactly what they want to do. There is a plethora of
J2EE-related technologies out there, especially if you include vendor-specific
features. Having it all be enabled at the same time would unnecessary get in
the way of a power user, not to mention effect performance of build, etc. Also,
there might be features in this list provided by vendors not affiliated with
the server implementer.
4. I want to be able to enable (or
disable) design functionality for an existing component. I initially created a
standards-based component, but now want to add a server-specific capability to
it.
Switch server target in project properties from
generic to proprietary.
While some users might be
happy with going back and forth between 1 and 2, the type of user who would
want the flexibility of 3 would want the same flexibility after the component
is created.
5. Allow ISVs to develop features
independently and have them merge seamlessly in the same component.
I guess I don’t really understand this one.
Let me clarify. Features
allow the user to mix functionality coming from WTP, server vendors, and other
value-add providers in a single component/project. Features provide a standard
well-defined way for functionality to be enabled and disabled per
component/project. There is a single set of wizard that everyone uses. Vendors
don’t have to roll their own. Vendors are no longer faced with the dilemma
of “does installing my plugins ‘polute’ all WTP projects with
functionality that I am adding or do I have to create some sort of ‘add
functionality’ action that would be specific to my plugins and the user
would have to know about or maybe I need to create a new component type and a
wizard to go along with it.” Everyone would solve this problem in a
different way. There would be no consistency. With features we have
consistency. If a user knows how to enable one feature, they know how to enable
any feature.
To be clear, this proposal is not designed
to somehow better address the multiple components per project scenario. This
proposal would still be viable if there were no components and project always
corresponded to a module. What it does is go beyond what is currently possible through
associating a project with a runtime. With features, you can also manipulate
the build, lay down feature-specific metadata and other resources…
basically its wide open, which is good since I doubt we can anticipate all the
use cases right now.
Features also enable a vendor not
affiliated with the server runtime provider to add functionality to the
components that will be published on that server. For instance, a vendor might
take advantage of some server’s extensibility to write a server-side
extension and want to add Eclipse-based facilities to help author applications
that will use that server-side extension. Since this vendor is not affiliated
with the server vendor, they cannot effect the implementation of IRuntime, etc.
They need some other hooks. The feature infrastructure provides them the hooks
necessary to effect classpath, build, etc.
I hope this clarifies things a bit.
- Konstantin
From:
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of John Lanuti
Sent: Wednesday, May 11, 2005 6:44
AM
To: wtp-dev@xxxxxxxxxxx
Subject: Re: [wtp-dev] flexible
project & server api changes - please review
Ted and Konstantin,
Thanks
for taking the time to put this proposal and design doc together. It
looks well thought out.
However,
being as we are already into the M5 milestone of a rapidly approaching release
date and the drastic nature of the change in terminology and
code
required, I feel the community is warranted some defense of the proposal.
Why
should we do it? What problem are we trying to solve? What are the risks?
I see the objectives below, but what is driving those objectives?
How
do features solve the given use cases better than server targetting?
Use
Cases:
1. Create a standards-based component. Hide UI that adds
non-standard features to my application. Want to be able to simultaneously
publish and test on multiple different server types.
Use a generic server container server target, something open source,
not propiertary.
2. Create a component with access to all available
features supported by a given server type. Show me everything; I am not
concerned about portability.
Use a propietary server target such as BEA.
3. Create a component with a carefully chosen set of
features enabled. I have a particular architectural model in mind. For example,
I know that this web module will be used to implement a webservice, and should
not contain UI.
Forcing a user upfront to know what features they want ahead of time,
seems like a very intimidating out of the box experience.
4. I want to be able to enable (or disable) design
functionality for an existing component. I initially created a standards-based component,
but now want to add a server-specific capability to it.
Switch server target in project properties from generic to propietary.
5. Allow ISVs to develop features independently and have
them merge seamlessly in the same component.
I guess I don't really understand this one.
What do we gain by putting the feature on the component,
rather than the target on a project? If there are multiple components in
a project and they target different features,
then all of those features will be on the classpath
anyways for that project and subsequently all those components. So, what
do we gain?
I would assume the typical case is one component per
project, so in that case, how do features improve on server targets?
Seems like we are adding UI, and adding complexity?
Is this really going to be more simple in the end?
Ted, Konstantin, I may know some of the responses to these
questions because I had the chance to speak with you guys, but again, I just
want to make sure the whole community can
be in agreement and be put to ease that this proposal can
be contained for M5 and that there are very concrete problems that will be
solved that are not already solved. At this stage of
the game, I don't think that is asking too much.
Thanks for your time and efforts,
John Lanuti
Software Engineer, IBM Rational
jlanuti@xxxxxxxxxx
t/l 441-7861
"I'll be awful sometimes, weakened to my knees, but I'll learn to get by
on the little victories." - Matt Nathanson
"Ted Bashor" <tbashor@xxxxxxx>
Sent
by: wtp-dev-bounces@xxxxxxxxxxx
05/11/2005 04:11 AM
Please
respond to
"General discussion of project-wide or architectural issues."
|
|
To
|
<wtp-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
[wtp-dev] flexible project & server api
changes - please review
|
|
The
following document describes proposed changes to componentcore and server apis:
http://www.eclipse.org/webtools/development/proposals/Component_Feature_Proposal.html
A couple main objectives:
1) provide a nature-style api on flexible
project components
2) less direct coupling of a wtp project and
a particular IServerRuntime
Feedback is very welcome. I've gone ahead
and opened a set of bugs to track the tasks involved in getting this into m5.
These are all pending approval of the api change of course.
IFeature model, extension points - 94608
Integration with componentcore - 94609
feature selection panel - 94610
IRuntime changes - 94611
function group/feature interaction - 94613
Feature definition (large scale features) - 94614
New project wizard work (Features providing
DataModels) - 94615
feature lifecycle management - 94616
Structural builder moving to publish tasks - 94617
-- Ted
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev