-----Original Message----- From: Max Andersen Sent: donderdag 28 september 2006 6:12 To: Marshall Culpepper; Koen Aers Cc: jbosside-dev(a)lists.jboss.org; Tom Baeyens Subject: Re: About feature.xml and bundling plugins (WAS: jBPM Designer feature.xml needs to be updated) Koen, just to check. Remember to actually look at the *generated* feature.xml/plugin.xml when looking at what version numbers actually end up in there. This was what put me of for the first couple of times I saw this bug reported. I also said: No, we don't put concrete version numbers in there....but the distribution actually does. /max > 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-hom >> e/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. > > > -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate max(a)hibernate.org http://hibernate.org JBoss a division of Red Hat max.andersen(a)jboss.com