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

On 9/27/06, Koen Aers <koen.aers(a)jboss.com&gt; 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.