[jbosside-dev] Re: About feature.xml and bundling plugins (WAS: jBPM Designer feature.xml needs to be updated)

[Marshall Culpepper]

On 9/27/06, Koen Aers <koen.aers at jboss.com> wrote:
>
>
>
> In fact this is not true. Eclipse features *are* a packaging mechanism.
> A feature does not *need* anything by itself. Only the plugins in the
> feature have dependencies on other plugins. See :
> http://dev.eclipse.org/viewcvs/index.cgi/*checkout*/platform-core-home/d
> ocuments/plugin-versioning.html?rev=1.2 for a document stating this. The
> fact that you will not find any Eclipse project that references plugins
> in the feature.xml is due to the fact that they are at the source and
> perfectly capable of defining their own packaging units in which no
> feature contains plugins that appear also somewhere else in other
> features.


Yes, it is true that eclipse features are used for packaging, but the
feature itself also logically separates the idea of "your plugin" (or "1st
class plugin) from "external or dependency" plugin! There are many problems
with PDE build... one of the major ones being that the distribution options
are dismal at best, but not giving us clear separation is not one of those
problems! All of that being said I think something has been lost in the
debate. Dependencies that are declared in the feature.xml should be features
only. Technically it is possible to list plugin dependencies in the
feature.xml (and there are features in Eclipse Platform that do it) , but I
prefer that plugin dependencies are pulled from plugin.xml, where they
belong. Basically the only reason feature dependencies should be listed in
feature.xml <import.../> is if you are trying to pull in more functionality
than you necessarily need, or if you want the actual "feature" directory and
"feature.xml" that go along with that huge list of plugins in your
distribution. JBossIDE Core does this because we want to re-distribute stuff
that we don't necessarily "depend" on. Everything else should be in plugin
dependencies.. ie.....

feature.xml:
<feature id="org.jbpm.gd.jpdl.feature">
<plugin id="org.jbpm.gd.jpdl.ui" ../>
</feature>

plugin.xml:
<plugin id="org.jbpm.gd.jpdl.ui">
<requires>
<import plugin="org.eclipse.gef"/>
</requires>
</plugin>

Instead of duplicating the "org.eclipse.gef" requirement as a <plugin/> in
feature.xml

As a matter of fact after exploring the different Eclipse projects a bit
> I have found evidence that what you say is not true. Have a look at the
> attached feature.xml files for the rcp feature and for the equinox
> feature and see that they are exactly using the 'evil' way of doing
> things. And I am sure that if I look a bit around I will be able to find
> plugin providers (that are not part of the Eclipse overall project) that
> have also feature.xml files containing references to third party plugins
> in the <plugin> tags.



IMO the two features that you have shown aren't adequate evidence... both of
these features are using what I consider to be "core" plugins of the Eclipse
SDK/RCP/platform. These plugins are mixed and matched all over the place to
create different configurations and feature sets etc. To look at something
more similar to our use case I think you need to take a look at an WTP
feature which has many "backward" dependencies like we do. If we look at
features/org.eclipse.wst.xml.core/feature.xml I think we will see something
which is much more "common" place in 2nd/3rd tier features.

I've attached the file for review (and if you look at pretty much any other
WTP feature you will notice the same pattern).

If you notice, only plugins that are actually 1st-tier are listed as
<plugin>. All dependencies are listed as "imports" via feature-import (in
this case Platform, RCP, EMF, XSD, etc). This, IMO is the model we should be
following since it is about as close as you can get to our use case in a
standard eclipse feature.

> This thing we are doing here (with using <plugin> instead of
> > <import>) is actually in the same ballpark since it breaks
> > updatemanagers and depedency checking.
>
> Again, I have completely no evidence that this is happening. In fact,
> the JIRA issue you mention is happening because the update manager is
> looking for particular versions of the plugins stated in the
> feature.xml. But you don't have to state these versions in your
> feature.xml explicitly. If you do not state them explicitly any version
> that is available on the update site will satisfy the requirements.


Yes this specific bug is related to a "specific" version of a plugin listed
in the plugin.xml. It should be noted that ever since 3.2, "0.0.0" for your
plugin id is now updated at build time to be the "exact" version that was
there at build time. It is no longer resolved at runtime meaning
dependencies as <plugin/> should NEVER happen!

There is *much* more granular control over dependency versioning in the
<requires><import/> than in <plugin/>. Basically in the plugin tag you have
2 options:
1) A specific version (bad)
2) 0.0.0 (change to specific version @ build time). (good -- but user still
sees a specific version at the end of the day in their distribution which is
*BAD BAD BAD* for dependencies)

In the import tag you have much more control:
1) You don't have to specify a version at all, meaning it should work with
*any* version of the plugin (there is no static version changing at build
time here)
2) Specify a certain version, and use a "match" qualifier that can be
"equivalent" "greater" "less", etc etc.... this gives us MUCH more control
over what we work with and what we don't. This will allow users to upgrade
to i.e. 1.5.1 while we are still turning the gears on our next release.



-- 
Marshall Culpepper
marshall.culpepper at jboss.com
JBossIDE Team Lead
JBoss, a division of Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20060927/3ff442bd/attachment.html