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

[Timothy Deboer <deboer@xxxxxxxxxx>]

Hi Konstantin,

Some more feedback:

1. I know you're gonna disagree :),
but I still don't see associating the features with components instead
of projects. So much of the Eclipse infrastructure is built around projects
(builders, classpath, natures, etc) that there are going to be lots of
conflicts when you have multiple modules in a projects. For example, adding
a feature to an EJB module will almost definitely apply it to the Web module
in the same project, regardless of whether that makes any sense. The feature
UI will be confusing (sorry, you can't add that feature because there is
another module in the same project that it conflicts with), and UI added
by features will probably be filtered by module type anyway. I'd rather
just admit that there are limitations with having multiple modules in the
same project and do this at the level we can support.

2a) Calling a no-op method _does_ impact
performance, and even a single one could impact it badly. Features will
most likely be spread out over several plugins, and activating the plugins
to call the no-op method could involve a significant performance and memory
hit. Once features start to be exploited it is likely that there will be
lots of features, and we can't trust that add-on features won't have large
dependancies or slow startup. This has to be designed in a way that it
won't matter or features will become a performance nightmare.
b) Just curious, but why a chain (or
what do you mean by 'chain') instead of separate handlers? I do agree that
we should stick with existing API patterns as much as possible to keep
things consistent, but only where it makes sense. In this case, the configure/deconfigure
would work just as well as an addFeature/removeFeature, but as in 2a) I
would argue against using an activate/deactivate model. Once we remove
these two methods, I'm not sure whether it still makes sense to follow
the nature API.

5. I thought we had discussed a two
level approach, where the user would be prompted with a list of features
as well as a secondary list of available runtimes. By default, the runtime
setting would be set to something like "no particular server".
The user could select features and watch the available runtimes disappear
(or be grayed out), or they could pick a real runtime and watch the same
happen with the features. Once the user clicks OK, if they are set to "no
particular server" then the features would grab the jars from whereever
they wanted to - out of the plugins or maybe out of a random runtime if
they didn't have their own copy of the jar. If the runtime setting was
used, then the classpath would be pulled from that exact runtime. I'm not
tied to this particular implementation (and it may not be do-able in 1.0
anyway), but we do have the requirement that the user has the option of
picking a particular runtime and getting all of the classpath from there.
I agree with your comments, but I don't
think we can do this in a consistent manner unless there is a weak runtime
association, or some sort of concept of "feature helpers" so
that a particular runtime can help the feature obtain the classpath (or
some other properties) when the user has picked a particular server. Just
to be clear, this would have to be kept general and I am not suggesting
adding a JDT requirement.

BTW, what does the feature run class
implement? I'm assuming there would be an abstract subclass of IFeature
that would have the virtual component?

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

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

05/12/2005 01:09 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

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. 
The problem is
what happens if you do end up with multiple components in a project that
are of a different type… an ejb and a webapp. The set of features applicable
to each is different. Some of the effects of feature application will obviously
mix (like classpath), but some may not (like ui). If we intend to support
multiple components per project, I don’t see any way that we can avoid
associated features at the component level.

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. 
The activate/deactivate
methods are certainly not critical to this proposal. Just so I understand,
if we don’t have these methods, how would a feature register/derigister
a listener? I don’t think using a nature works, natures only have configure/deconfigure
methods. Like I said, not critical, just gives the feature writer a well-defined
place to do setup and teardown. Otherwise they have to figure out how to
do it on their own. Some do it right. Some don’t. 
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.

My understanding
is that we would only support features on WTP projects, which will have
our flexible project model nature… I also don’t think there is a performance
impact. The IFeature implementations will have to be instantiated when
workspace is opened, so the plugin that they are in is going to be loaded
anyway. Calling a no-op activate method would not impact performance.
   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.

I can see a design
where configure/deconfigure operations are provided by a chain of delegates.
The feature definition might provide the first one, but someone may come
along and add more. Do people care if we stay consistent with the nature
api on this (which has configure/deconfigure methods, not delegates)?

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. 
Not critical.
On the other hand it’s real cheap to implement and has two arguments for
it: (1) reduction in verbosity (even in the first release), and (2) some
degree of protection from feature splits for server adapter implementers.
For instance, if we define a feature group "j2ee-14" and a server
adapter specifies that it supports all of the features in that group then
come next release if we decide to split some features there is no impact
on the server adapter.

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". 
Yes “one-of-feature”
is the same as “feature sets”. The terminology and capabilities are borrowed
directly from natures. There were several use cases that we came up for
this. The two that I remember of the top of my head is the top level features
(web, ejb, etc) and different web service implementation (doclet, annotations,
manual). 
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. 
Just to be clear,
the thing that we do not like is having the project be associated with
a server runtime. I don’t have any problem with letting a particular feature
implementation associate itself with a runtime. I should have included
it in the spec, but let me try to describe here the way we talked about
handling that use case. WTP would define a feature like "j2ee.webapp".
A server vendor would provide a feature like "websphere.j2ee.webapp"
that would depend on “j2ee.webapp". When the user goes to create
a webapp, they can either choose just “j2ee.webapp”, in which case they
have to do more work to specify where jars are located, etc., or they can
choose “websphere.j2ee.webapp”, in which case they will be prompted to
select a websphere runtime and it’s very similar to how it behaves right
now. 
Is this sufficient
or do we need to come up with something else?
Hope this helps
and thanks for reviewing the spec.
- Konstantin_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev