Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [wtp-dev] flexible project & server api changes - please review


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,

T
hanks 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


Back to the top