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