Hello Patrick
[snip]
It appears features can pre-req plugins, but not other
features. It seems like it would be nice to allow features to pre-req
other features. In fact, I think for my purposes, having plugins reference
features would be the nicest thing to do. For instance, I might have a
feature that installs some non-plugin data, which is actually a runtime library,
meant to be consumed by a programmer using Eclipse. As an example, most of
the 'runtimes' and 'technologies' stuff out of WSDD. I might also have an
Eclipse plugin that can be used against the runtime libraries. Note that
I'm not going to push the issue of cross-linking jars within plugins, more the
user experience of "I've installed some runtimes, now I want the tools".
Installing the tools without the runtimes basically doesn't make sense,
but installing the runtimes without the tools does. So, what I really want
is for the plugin, whi! ch will likely be a feature in it's own right, to
pre-req the feature that contains the runtime. Also, I'm curious about not being able to nest features.
It sort of seems like a natural thing to do. If you look at WSDD, it
would be wonderful if you could press a button and download ALL the features,
instead of having to pick all of them individually. ie, pick the 'All WSDD
Features', which just pointed to all the individual features.
<CE>
Sigh ;-)
I knew this would come... ok let me explain
our vision
let's focus on the job. WHen you create a 'product' (either
runtime or tool) you know the exact list of plugins this products require (in
our example there will be runtime1, runtime2, tool1 and tool2).
When you
build the runtime product, you will need runtime1 and runtime2 plugin
When
you need tool product you will need tool1 and tool2 but you will require plugin1
and 2 to be installed.
If you go the way -require feature- you will have
to 'require' the 'runtime' product in the 'tool' product with some kind of
policy (if not found install or if not found fail)
if you do not go this
way, ie you have the tool product require all the 4 plugins, you can still
achieve the same
1) if you package the runtime plugins they will be installed
if they do not exist
2) if you do not package the runtime plugins and they
are not already installed, the install will fail
of course it means you
produce the 4 plugins, if you do not produce the 4 plugins, you still have the
require tag in feature.xml that allows you to loosely reference another feature
(like a 3rd party or a feature you didn;t produce)
The philosphy of
having a complete list os the following. At one point your tester will say. yep,
this configuration is the correct one. And what you will want to do is to take a
snapshot of the config and tag it 'supported' (ie you will want to get the
complete list of all the plugins neede for the tool) Some of them you may have
on your server, some you may not. The spec also allows you to separate the
plugins/non-plugins from the feature.xml description, so you can have more than
one feature.xml pointing to a plugin.
Hopefully , future tools will help
you create the snapshot.
Re the pick-all feature, cut and paste all
plugins in a new feature.xml.
I know your answer will be, "well, I want to
have this feature point to other features so I will not have to change it... I
will just change the pointed features ...et voila :-)"
My answer is , yep,
but because you are a professional, you will try to test this 'All features'
feature. And thus come back to case #1 where, when you are satisfied with the
feature, and your organization will support it, you will tag it, thus create the
list of the exact plugins.
As stated before, if you still want some kind
of 'pointers' check the require tag of feature.xml...
One of your concern
will be, ok but what if there is just a new version of a plugin... If your
support team wants to support it, they will need to test it, thus back to
#1.
The goal is to have the development team package plugins, the
test/build/release team to create the feature.jar and the Site admisnistrator to
place the different files in the correct places.
Let us
know
</CE>
Lastly, what is the
current state of this work in Eclipse, and do you have any milestones for it, if
it's not functional right now? <CE>
Sigh 2 ;-)
I
broke it... M4 will not work.
The nightly build may be what you want unless
you can wait for integration build.
I am attempting to eat my own
dog foood and *may* release a fix for M4 on an http site ... can you host it
?
</CE>
Patrick
Mueller
patrick_mueller@xxxxxxx
<CE>
Christophe
Elek
celek@xxxxxxxxxx
</CE>