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

[Timothy Deboer <deboer@xxxxxxxxxx>]

Hi,

I'm still reviewing the doc, but I've
got a few questions and comments so far:

1. The first is a follow-up from one
of John's initial comments - why is this at the component level and not
the project? All three of the "what would a feature do" actions
that you describe are project level actions and fail in the case of multiple
components per project. Since the majority of the platform is done at the
project level, what is the point of doing it more fine grained? Even though
we support multiple modules per project, we already know that there are
several limitations imposed by this that we can't change. I'd rather just
do this at the project level where it makes sense to put in project properties
dialogs, etc.

2. On IFeature there are two sets of
activation methods - configure/deconfigure and activate/deactivate. I think:
   a) We should only have
one set, which is called when the feature is added/removed. If features
require additional activation then they can add a Nature to the project.
If we support this then we'd have to have our own nature on every project
which activated the features, and we could have a performance problem since
many features would not require activation on every workbench startup.
We should leave those issues to the existing platform mechanisms.
   b) Instead of having a
single delegate, I'd vote for something similar to the current runtime
target hander. This decouples the feature implementation from the definition
of the feature and allows extensibility - someone else can come along and
provide additional support or actions to an existing feature.

3. I don't understand the real need
for feature groups, and I think this is something that we could easily
add in v1.1 or v2.0 if we start to get a lot of features.

4. I assume "one-of-feature"
is the same as "feature sets"? Do we forsee the requirement for
real exclusive features in the first release? If not, a much simpler solution
to the problem is that when you create a component of a specific type you
are required to choose (or automatically based on the J2EE level) a feature
with the same name. So if I create an EJB module, I have to pick one version
of the "j2ee.ejb" feature. From here, we can show only the sub-features
that are supported by this feature. We may still need to label them as
"base features" or have non-component specific features, but
I think those are different concepts than "one-of".

5. One of the requirements we discussed
was the ability to have features pick up their runtime jars from a specific
runtime. In some cases even the JDK must come from the runtime. However,
there is no link between them in this spec - features are free to get their
libraries from wherever they choose. I know Konstantin will cringe :),
but one of our requirements is like #2 provided that the jars are automatically
picked up from the user's chosen runtime. Making every feature to come
up with their own way to do this will be very painful to the user. We need
to find a way to support this requirement and keep the existing function
in WTP.

Thanks,
Tim deBoer
WebSphere Tools - IBM Canada Ltd.
(905) 413-3503  (tieline 969)
deboer@xxxxxxxxxx

John Lanuti <jlanuti@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

05/11/2005 01:37 PM

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

To	<wtp-dev@xxxxxxxxxxx>
cc
Subject	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,

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