Re: [wtp-dev] flexible project & server api changes - please review

[John Lanuti <jlanuti@xxxxxxxxxx>]

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