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

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
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."

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

The following document describes proposed changes to componentcore and server apis:

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

Back to the top