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

[John Lanuti <jlanuti@xxxxxxxxxx>]

Konstantin and Ted,

Thanks very much!  This does clarify
things a great deal for me personally and I'm sure for other WTP folks.
 I'm all for
the component leads Naci mentions weighing
in and declaring that they can contain this for R1.  And if they can,
then there should be
no reason we don't add the feature infrastructure.

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

"Konstantin Komissarchik" <kosta@xxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

05/11/2005 12:27 PM

Please respond to
"General discussion of project-wide or architectural issues."

To	"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
Subject	RE: [wtp-dev] flexible project & server api changes - please review

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_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev