1. Actually, I don’t disagree. It’s
just the question of whether we want to keep up the appearances of multiple
component support or not. If features are a property of a project, then I think
we should stop pretending that the multiple component case is supported.
2a. Couple of things to clarify here. I
don’t think you are going to be able to avoid loading the plugins that
implement the features that are referenced by a project as soon as the project
is opened. So given that the plugin is going to be loaded, I don’t think
that instantiating a feature object and calling it’s no-op activate
method is going to noticeably effect performance. Also, natures don’t
have activate/deactivate methods (only configure/deconfigure). What happens
with natures is that the nature object is constructed when the project is
opened. That gives you a place to do your “activate” logic. Not
sure what you would do for “deactivate”; maybe use the finalize
method or something. I just thought activate/deactivate was a more explicit
model. But I don’t think you object to the api, but rather to the notion
that the feature class/plugin has to be loaded when the project is opened. I don’t
think we can avoid this.
2b. What I meant by a chain is that there
would be a set of them that would be called one after another. Also, as I
mention in 2a, activate/deactivate methods are not part of nature api, but
configure/deconfigure are. I am not set, by any means, on using configure/deconfigure.
I personally like the set of delegates approach, but I just want to know if
people feel strongly about following nature api or not.
5. I thought we talked about doing that
for server/runtime types instead of actual runtime instances. More like a
filtering mechanism than anything else. In any case, we can spend a lot of time
going back and forth on this over e-mail. Let’s try this over the phone,
Monday perhaps?
BTW. Yeah, there will be an abstract class
that would implement all of the IFeature methods down to no-op implementations
of activate/deactivate/configure/deconfigure. The feature class just overrides
as necessary.
- Konstantin
From:
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Timothy Deboer
Sent: Friday, May 13, 2005 2:44 PM
To: General
discussion of project-wide or architectural issues.
Subject: RE: [wtp-dev] flexible
project & server api changes - please review
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
