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

[Max Rydahl Andersen]

> So what exactly is the *right* way of bundling features Max? Is it a
> distribution without *any* dependency on plugins that reside in some
> other feature? If this is the case than I have to totally disagree. I
> don't want my user's to go through the pain of installing WTP only for
> the fact that I happen to use their XML editor plugin.

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 pde auto builds exactly what is needed and if you look around on all
eclipse plugins etc. they are package like this so they fit togehter.

The other is distribution which is your feature + what is a good default  
packaging.

Of course we want the last since we have like a zillion other plugin we  
dependent
on, but that should not make you write a feature.xml that specifies things  
that are *not* true.
e.g. that your feature provides WTP plugins - no, it should say it needs  
to *import* them.

>> Because if user updates WTP 1.5 to WTP 1.5.1 it won't work
>> anymore since we have *specifc* version numbers in there.
>
> I am not exactly sure what you mean with this but if I understand well
> you want to provide forward compatibility between a specific release of
> your plugin and some future release of WTP? That is something that I
> don't want to do, in fact. The thing that is IMO needed is certifying
> that a particular release of your plugin works with a particular
> configuration of Eclipse/WTP/GEF/... And nothing more. If user's want to
> mix and match their environments and use configurations that I do not
> certify to work they are of course free to do so, but I will not support
> it.

So you would rather make the update mechanism in eclipse not work with  
Callisto provided WTP;s ? (including the WTP you actually work with) ?

>> The ide support for building plugins is not meant for building of
>> *distribution* of
>> other dependent features, but for building *deployable*
>> features/plugins into existing projects.
>
> All right, building using the IDE may not be fit for distributing the
> plugins/features. But the Eclipse PDE build is meant to this and this
> also breaks if I do not include the dependencies between <plugin> tags.
> So it seems to me that this is the way the Eclipse guys envisioned
> constructing features to be distributed... If not, it is a bug and the
> system should be changed to use some other mechanism (a la using
> Marshall's tasks).

If you could please find one eclipse.org distribution that uses <plugin>  
instead
of <import> for their feature.xml/plugin.xml then let me know!

Eclipse doesn't
WTP doesn't
TPTP doesn't
etc.
etc.

they all are "good" citizens specifying we work with *this* version and  
onwards. e.g. 1.5.x

>> > Can someone convince me with some real advantages?
>>
>> Because it breaks updatemanager, because noone else do it
>> this way, because we should not dictate specific versions
>> down to fix/micro number.....enough reason ? :)
> I am still not convinced as a matter of fact.
> - If no one else does it that way, how do these other guys do it then?
> All the Eclipse build mechanisms work in this way... Besides, this is
> really the same argument that the EMF guys use to convince you to use
> EMF, Max ;-)

No - I don't see *any* eclipse build doing this.

Koen, you know I bitched hard about WTP not managing their versioning, not  
remembering
to bump up versions ?

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.

> - How exactly does the update manager break? Normally the update manager
> should only download plugins from the site that are not yet present in
> the installation or if the installed version is lower than the needed
> version.

And this does not happen. Or rather what do happen is that it figures out  
it has versions that are
new enough but when it startsup it sees that hey - you have a plugin X  
version Y that is part of some
other feature than the one we bundle + the plugin is "too" new.

> - I do not understand your statement of 'dictating specific versions'.
> These specific versions are simply not specified in the <plugin> tags so
> that should pose no problem. Or do I miss something?

Marshall, do you have the jira number for the case where a users shows how  
it breaks stuff?

ah here it is: http://jira.jboss.com/jira/browse/JBIDE-367

please read this and the linked hibernate related elements.

And do ignore the "he wants to use I build" which we don't really care  
about...it is the fact
that he is actually using something that is comptabile if you look at the  
versionnum/dependencies etc.

/max

>
>
>
>
>> -----Original Message-----
>> From: Max Andersen
>> Sent: woensdag 27 september 2006 16:08
>> To: Koen Aers; Marshall Culpepper; jbosside-dev at lists.jboss.org
>> Cc: Tom Baeyens
>> Subject: Re: About feature.xml and bundling plugins (WAS:
>> jBPM Designer feature.xml needs to be updated)
>>
>>
>> > - Neither the Eclipse IDE build (Export->Deployable
>> Features) nor the
>> > Eclipse PDE build (with the myriad of customTargets.xml,
>> > mainTargets.xml, etc files) support apparently building a
>> feature and
>> > bundling additional plugins where you don't specify the
>> plugins that
>> > you want to have bundled between <plugin> tags in your feature.xml
>> > - Why exactly is it then that our 'old/current' way of
>> bundling things
>> > is so 'wrong'?
>>
>>
>>
>> > The only real valuable reason I see (for now) is Robs comment: 'I'm
>> > just happy manual updating will go away'. But then I lose
>> the ability
>> > to build from the Eclipse IDE... Moreover, I always thought
>> that the
>> > feature.xml *has* to specify all plugins that the feature bundles,
>> > there is nothing 'evil' about that as I understand it.
>> Additionally,
>> > doing this process 'automagically' through an ant task can indeed
>> > solve a lot of manual work, but then the information has become
>> > implicit and hence undocumented. I may be way late with all my
>> > ramblings and thoughts, but I am not so sure anymore if
>> this is the way to go.
>>
>> The ide support for building plugins is not meant for building of
>> *distribution* of
>> other dependent features, but for building *deployable*
>> features/plugins into existing projects.
>>
>> > Can someone convince me with some real advantages?
>>
>> Because it breaks updatemanager, because noone else do it
>> this way, because we should not dictate specific versions
>> down to fix/micro number.....enough reason ? :)
>>
>>
>> --
>> --
>> 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
>>



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