On 9/27/06, Koen Aers <koen.aers@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!