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

[Marshall Culpepper]

Sorry forgot to attach the feature.xml.. attached now.

On 9/27/06, Marshall Culpepper <marshall.culpepper at jboss.com> wrote:
>
>
> 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.
>
>
>
> --
> Marshall Culpepper
> marshall.culpepper at jboss.com
> JBossIDE Team Lead
> JBoss, a division of Red Hat
>



-- 
Marshall Culpepper
marshall.culpepper at jboss.com
JBossIDE Team Lead
JBoss, a division of Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20060927/c078bb3a/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: feature.xml
Type: text/xml
Size: 2617 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20060927/c078bb3a/attachment.xml