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

[Koen Aers]

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. 

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

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

> > 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 ;-)
- 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.
- 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?




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