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

[Koen Aers]

I checked this and there is no generation of feature.xml whatsoever...
The feature.xml that is packaged in my distribution is the exact same
feature.xml that I created in the IDE...

Regards,
Koen 

> -----Original Message-----
> From: Max Andersen 
> Sent: donderdag 28 september 2006 6:12
> To: Marshall Culpepper; Koen Aers
> Cc: jbosside-dev at 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 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-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 at hibernate.org
> http://hibernate.org
> 
> JBoss a division of Red Hat
> max.andersen at jboss.com
>