[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [wtp-dev] flexible project & server api changes - please review
|
Hi Kosta,
I have a scenario that I wish to understand if we wish to cover or
not. If a vendor wants to add a BPEL feature to WTP and let' s
assume that all this feature needs to run is a j2ee application
server. Is this a scenario covered by the usecase 5. If that is a
scenario we wish to cover, what will be the way for a server adapter
to support this feature since as far as I can understand from the
document features supported by a server adapter are limited to those
declared in plugin.xml.
--
Gorkem Ercan
On 5/11/05, Konstantin Komissarchik <kosta@xxxxxxx> wrote:
>
>
>
> 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
>
>
>
