RE: [jbosside-dev] Re: About feature.xml and bundling plugins (WAS: jBPM Designer feature.xml needs to be updated)
by Tom Baeyens
| Hi guys,
|
| I had a chat with Koen today about to get to the bottom of
| this fine discussion.
|
| To make the long story short here is what will be done short term:
|
| 1) Koen will make a feature.xml with import instead of plugin
| references so JBossIDE 2 beta2 can get out.
euh...
| 2) Koen will also work on a solution for Jbpm's starterkit
| which depends on having a feature.xml that will let include
| the plugins.
| (One suggestion was that they would have two feature.xml's
| one for the 'no dependencies' feature.xml and another
| 'starterkit' feature.xml that refers to the 'no dependencies'
| feature.xml)
huh ?
| There probably will/can be issues in this aspect but the
| faster we get this going (e.g. have the jboss ide build
| actually running with the files Koen fixes today) the faster
| we can move forward - I assume this will mostly affect Koen
| and Marshall so please speak up guys if you need help with
| solving/fixing some of this.
maybe...
| Koen, please correct me if my description of the short-term
| conclusion is wrong ;)
|
| Longer term we will have to figure how jbpm's IDE parts fits
| into the overall picture of JBossIDE build system; but that
| will be another mail/discussion when we get over the bumps of
| releasing jbosside 2 and jbpm 3.something :)
whatever...
| p.s. a side conclusion is that feature's in Eclipse is broken
| and that we need a beer drinking contest in Berlin to get to
| a final settlement of how to fix it ;)
YES! I ABSOLUTELY AGREE! COUNT ME IN !!!
|
| /max
19 years, 1 month
RE: [jbosside-dev] Re: About feature.xml and bundling plugins (WAS: jBPM Designer feature.xml needs to be updated)
by Koen Aers
So the feature.xml is adapted, 'evil' <plugin> tags removed and replaced
by 'good' <import> tags. The codebase is retagged with jbpm_gpd_3_0_12.
Everybody should be happy now ;-)
Regards,
Koen
> -----Original Message-----
> From: Max Andersen
> Sent: vrijdag 29 september 2006 15:37
> To: Koen Aers; Marshall Culpepper; jbosside-dev(a)lists.jboss.org
> Cc: Tom Baeyens
> Subject: Re: [jbosside-dev] Re: About feature.xml and
> bundling plugins (WAS: jBPM Designer feature.xml needs to be updated)
>
> On Fri, 29 Sep 2006 15:33:35 +0200, Koen Aers
> <koen.aers(a)jboss.com> wrote:
>
> > Max,
> >
> > Your summary is basically correct. I will not do the two
> feature.xml
> > part as I will reuse Marshall's ant task though.
>
> Ah ok, cool ;)
>
> > If there is going to be
> > two features, this will be part of the long term plan.
>
> ok.
>
> > I am in any case most interested in the midterm plan that will be
> > happening in Berlin. ;-)
>
> Me too ;)
>
> /max
>
> > Regards,
> > Koen
> >
> >> -----Original Message-----
> >> From: Max Andersen
> >> Sent: vrijdag 29 september 2006 14:17
> >> To: Max Andersen; Koen Aers; Marshall Culpepper;
> >> jbosside-dev(a)lists.jboss.org
> >> Cc: Tom Baeyens
> >> Subject: Re: [jbosside-dev] Re: About feature.xml and bundling
> >> plugins (WAS: jBPM Designer feature.xml needs to be updated)
> >>
> >> Hi guys,
> >>
> >> I had a chat with Koen today about to get to the bottom of
> this fine
> >> discussion.
> >>
> >> To make the long story short here is what will be done short term:
> >>
> >> 1) Koen will make a feature.xml with import instead of plugin
> >> references so JBossIDE 2 beta2 can get out.
> >>
> >> 2) Koen will also work on a solution for Jbpm's starterkit which
> >> depends on having a feature.xml that will let include the plugins.
> >> (One suggestion was that they would have two feature.xml's one for
> >> the 'no dependencies' feature.xml and another 'starterkit'
> >> feature.xml that refers to the 'no dependencies'
> >> feature.xml)
> >>
> >> There probably will/can be issues in this aspect but the faster we
> >> get this going (e.g. have the jboss ide build actually
> running with
> >> the files Koen fixes today) the faster we can move forward
> - I assume
> >> this will mostly affect Koen and Marshall so please speak
> up guys if
> >> you need help with solving/fixing some of this.
> >>
> >> Koen, please correct me if my description of the short-term
> >> conclusion is wrong ;)
> >>
> >> Longer term we will have to figure how jbpm's IDE parts
> fits into the
> >> overall picture of JBossIDE build system; but that will be another
> >> mail/discussion when we get over the bumps of releasing jbosside 2
> >> and jbpm 3.something :)
> >>
> >> p.s. a side conclusion is that feature's in Eclipse is broken and
> >> that we need a beer drinking contest in Berlin to get to a final
> >> settlement of how to fix it ;)
> >>
> >> /max
> >>
> >>
> >>
>
>
>
> --
> --
> Max Rydahl Andersen
> callto://max.rydahl.andersen
>
> Hibernate
> max(a)hibernate.org
> http://hibernate.org
>
> JBoss a division of Red Hat
> max.andersen(a)jboss.com
>
19 years, 1 month
RE: [jbosside-dev] Re: About feature.xml and bundling plugins (WAS: jBPM Designer feature.xml needs to be updated)
by Koen Aers
Max,
Your summary is basically correct. I will not do the two feature.xml
part as I will reuse Marshall's ant task though. If there is going to be
two features, this will be part of the long term plan.
I am in any case most interested in the midterm plan that will be
happening in Berlin. ;-)
Regards,
Koen
> -----Original Message-----
> From: Max Andersen
> Sent: vrijdag 29 september 2006 14:17
> To: Max Andersen; Koen Aers; Marshall Culpepper;
> jbosside-dev(a)lists.jboss.org
> Cc: Tom Baeyens
> Subject: Re: [jbosside-dev] Re: About feature.xml and
> bundling plugins (WAS: jBPM Designer feature.xml needs to be updated)
>
> Hi guys,
>
> I had a chat with Koen today about to get to the bottom of
> this fine discussion.
>
> To make the long story short here is what will be done short term:
>
> 1) Koen will make a feature.xml with import instead of plugin
> references so JBossIDE 2 beta2 can get out.
>
> 2) Koen will also work on a solution for Jbpm's starterkit
> which depends on having a feature.xml that will let include
> the plugins.
> (One suggestion was that they would have two feature.xml's
> one for the 'no dependencies' feature.xml and another
> 'starterkit' feature.xml that refers to the 'no dependencies'
> feature.xml)
>
> There probably will/can be issues in this aspect but the
> faster we get this going (e.g. have the jboss ide build
> actually running with the files Koen fixes today) the faster
> we can move forward - I assume this will mostly affect Koen
> and Marshall so please speak up guys if you need help with
> solving/fixing some of this.
>
> Koen, please correct me if my description of the short-term
> conclusion is wrong ;)
>
> Longer term we will have to figure how jbpm's IDE parts fits
> into the overall picture of JBossIDE build system; but that
> will be another mail/discussion when we get over the bumps of
> releasing jbosside 2 and jbpm 3.something :)
>
> p.s. a side conclusion is that feature's in Eclipse is broken
> and that we need a beer drinking contest in Berlin to get to
> a final settlement of how to fix it ;)
>
> /max
>
>
>
19 years, 1 month
[jbosside-dev] RE: About feature.xml and bundling plugins (WAS: jBPM Designer feature.xml needs to be updated)
by Koen Aers
But I *am* building a completely separate thing along with the JBoss IDE
distribution. Our jBPM Starter's Kit contains the jBPM GPD feature
without all the other JBoss IDE stuff. And this is exactly what I am
worried about and why I am looking at this with so much suspicion...
I am distributing the jBPM GPD feature as a standalone feature and I
certainly do not want to import the complete WTP feature only because I
am using the XML editor. So I repackage the plugins from the WTP feature
and I provide or distribute them in my own feature.
Besides, your statement does not hold. The Eclipse RCP feature is
packaged in the Eclipse core distribution and 'provides' some of the
plugins that happen also to be in the Equinox project and thus in the
Equinox feature. This is exactly the same situation as what I am doing
with WTP... The bottom line is that the feature is a way of packaging
and of distributing plugins.
Regards,
Koen
> -----Original Message-----
> From: Max Andersen
> Sent: donderdag 28 september 2006 6:20
> To: Koen Aers; Marshall Culpepper; jbosside-dev(a)lists.jboss.org
> Cc: Tom Baeyens
> Subject: Re: About feature.xml and bundling plugins (WAS:
> jBPM Designer feature.xml needs to be updated)
>
>
> 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(a)hibernate.org
> http://hibernate.org
>
> JBoss a division of Red Hat
> max.andersen(a)jboss.com
>
19 years, 1 month
[jbosside-dev] RE: About feature.xml and bundling plugins (WAS: jBPM Designer feature.xml needs to be updated)
by Koen Aers
I checked this and there is no generation of feature.xml whatsoever...
The feature.xml that is packaged in my distribution is the exact same
feature.xml that I created in the IDE...
Regards,
Koen
> -----Original Message-----
> From: Max Andersen
> Sent: donderdag 28 september 2006 6:12
> To: Marshall Culpepper; Koen Aers
> Cc: jbosside-dev(a)lists.jboss.org; Tom Baeyens
> Subject: Re: About feature.xml and bundling plugins (WAS:
> jBPM Designer feature.xml needs to be updated)
>
>
> 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(a)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-hom
> >> e/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(a)hibernate.org
> http://hibernate.org
>
> JBoss a division of Red Hat
> max.andersen(a)jboss.com
>
19 years, 1 month
[jbosside-dev] RE: About feature.xml and bundling plugins (WAS: jBPM Designer feature.xml needs to be updated)
by Koen Aers
>
> 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
19 years, 1 month
