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

[Max Rydahl Andersen]

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-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.
>
>
>



-- 
--
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