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

[Max Rydahl Andersen]

I just got to look at the two feature.xml you are attaching and these are
core features.xml - meaning this is what they do...define a feature.xml to
represent equinox and rcp.

If we were building a complete separate thing, e.g. something that does  
not need
to run in other peoples Eclipse IDE 3.2 then sure we could just redefine  
the
features.xml and plugin.xml as something completely seperate ...but that  
is not
what we are doing, right ?

Similar if we were building equinox and rcp based apps I would have a  
feature.xml
that referred to those two (via import not plugin)

We are an *IDE* building on top of the eclipse ide core features and those  
we
refer/link to those core features/plugin instead of saying that our  
feature actually
provides them. Our features *only* provides the  
org.jboss.*/org.hibrnate.*/org.jbpm.*/etc plugins
it does not provide org.eclipse.* stuff.

Not I'm writing "Our *feature* provides" not "Our *distribution* provides"
two *different* things.

/max

>>
>> There are two very different things:
>>
>> One is what goes into feature.xml that states what your
>> feature actually
>> *need* and then there is your distribution.
>> ...
>> The other is distribution which is your feature + what is a
>> good default packaging.
>>
>> Of course we want the last ...
>
>
> 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.
> 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.
>
>> 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.
>
> Regards,
> Koen



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