Skip to main content



      Home
Home » Eclipse Projects » Plugin Development Environment (PDE) » Cleanest way to allow plugin version ranges
Cleanest way to allow plugin version ranges [message #496401] Mon, 09 November 2009 16:54 Go to next message
Eclipse UserFriend
We have a 3.5 product built headlessly with PDE and p2.gathering=true that includes our Feature. The Feature includes several of our plugins, with version set to "0.0.0".

The Product runs well, but I found that I could not update individual plugins via the Dropins folder. The updated plugins just seemed to be ignored. Making an update site of the plugins and then updating fails with error messages such as "Only one of the following can be installed at once" and "Can not satisfy dependency from <our Feature> to <updated plugins>.

My conclusion is that the Feature.xml file (and subsequent metadata) specify exactly the version of the plugins created at build time, rather than allowing a range.

What is the easiest, correct way to allow a range of plugin versions to be allowed in our Feature, so that the plugins in the Dropins folder would be accepted?

Thanks,
MSacarny
Re: Cleanest way to allow plugin version ranges [message #496881 is a reply to message #496401] Wed, 11 November 2009 11:03 Go to previous messageGo to next message
Eclipse UserFriend
There are two approaches, the first is to change the feature to require
the plug-in instead of include it. This gets you the old update style
ranges of equivalent[1.2.3, 1.3.0), compatible[1.2.3, 2.0.0), or
greaterOrEqual. However, PDE/Build currently only builds included
plug-ins, not required ones. So you would need to build the bundles
separately and then have them (and their metadata) available to the
product build.

The other and perhaps simpler option is for the feature to have a p2.inf
beside the feature.xml. The p2.inf can add requirements to the feature,
and they replace the generated requirements that came from included
plug-ins if the name and namespace are the same.

feature: include org.eclipse.foo 0.0.0
p2.inf:
requires.1.namespace = org.eclipse.equinox.p2.iu
requires.1.name = org.eclipse.foo
requires.1.range = [1.0.0, 2.0.0)


If you are changing the requirement ranges for include features,
remember that the name for a feature's IU has ".feature.group" appended
to it.

http://wiki.eclipse.org/Equinox/p2/Customizing_Metadata

-Andrew

michael.sacarny@analog.com wrote:
> We have a 3.5 product built headlessly with PDE and p2.gathering=true
> that includes our Feature. The Feature includes several of our plugins,
> with version set to "0.0.0".
>
> The Product runs well, but I found that I could not update individual
> plugins via the Dropins folder. The updated plugins just seemed to be
> ignored. Making an update site of the plugins and then updating fails
> with error messages such as "Only one of the following can be installed
> at once" and "Can not satisfy dependency from <our Feature> to <updated
> plugins>.
>
> My conclusion is that the Feature.xml file (and subsequent metadata)
> specify exactly the version of the plugins created at build time, rather
> than allowing a range.
> What is the easiest, correct way to allow a range of plugin versions to
> be allowed in our Feature, so that the plugins in the Dropins folder
> would be accepted?
>
> Thanks,
> MSacarny
Re: Cleanest way to allow plugin version ranges [message #498361 is a reply to message #496881] Mon, 16 November 2009 10:26 Go to previous messageGo to next message
Eclipse UserFriend
Andrew,
That works very well. I use a different namespace statement for each plugin:

requires.12.namespace = org.eclipse.equinox.p2.iu
requires.12.name = org.eclipse.equinox.transforms.xslt
requires.12.range = 0.0.0

requires.13.namespace = org.eclipse.equinox.p2.iu
requires.13.name = org.eclipse.equinox.transforms.xslt.plugin
requires.13.range = 0.0.0

So, when I drop a new version of a plugin into dropins folder, eclipse uses it. HOWEVER - when I remove the plugin from dropins, eclipse ignores original plugin and update. Basically, this action strips the plugin completely from the project. I've tried -clean and -initialize, no luck. Is it possible to revert to original plugin?
Re: Cleanest way to allow plugin version ranges [message #513692 is a reply to message #498361] Wed, 10 February 2010 15:08 Go to previous messageGo to next message
Eclipse UserFriend
The p2.inf mechanism that worked very well for 3.5 is busted on 3.6M5!
Dropins once again does not allow us to update installed jars.

Any additional info on this, when it will be fixed, etc.?

Mike

[Updated on: Thu, 11 February 2010 14:23] by Moderator

Re: Cleanest way to allow plugin version ranges [message #514551 is a reply to message #513692] Mon, 15 February 2010 13:18 Go to previous messageGo to next message
Eclipse UserFriend
By paying scrupulous attention to start levels as indicated here:
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .pde.doc.user/tasks/pde_p2_builds.htm

it looks like I once again can get updated components accepted via dropins folder. The reason I have any entries here is because I needed to set org.eclipse.equinox.p2.reconciler.dropins (level=0,true) for proper enablement of dropins folder.
Re: Cleanest way to allow plugin version ranges [message #603347 is a reply to message #496881] Mon, 16 November 2009 10:26 Go to previous messageGo to next message
Eclipse UserFriend
Andrew,
That works very well. I use a different namespace statement for each plugin:

requires.12.namespace = org.eclipse.equinox.p2.iu
requires.12.name = org.eclipse.equinox.transforms.xslt
requires.12.range = 0.0.0

requires.13.namespace = org.eclipse.equinox.p2.iu
requires.13.name = org.eclipse.equinox.transforms.xslt.plugin
requires.13.range = 0.0.0

So, when I drop a new version of a plugin into dropins folder, eclipse uses it. HOWEVER - when I remove the plugin from dropins, eclipse ignores original plugin and update. Basically, this action strips the plugin completely from the project. I've tried -clean and -initialize, no luck. Is it possible to revert to original plugin?
Re: Cleanest way to allow plugin version ranges [message #604597 is a reply to message #603347] Wed, 10 February 2010 15:08 Go to previous messageGo to next message
Eclipse UserFriend
The p2.inf mechanism that worked very well for 3.5 is busted on 3.6M6!
Dropins once again does not allow us to update installed jars.

Any additional info on this, when it will be fixed, etc.?

Mike
Re: Cleanest way to allow plugin version ranges [message #604684 is a reply to message #604597] Mon, 15 February 2010 13:18 Go to previous message
Eclipse UserFriend
By paying scrupulous attention to start levels as indicated here:
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .pde.doc.user/tasks/pde_p2_builds.htm

it looks like I once again can get updated components accepted via dropins folder. The reason I have any entries here is because I needed to set org.eclipse.equinox.p2.reconciler.dropins (level=0,true) for proper enablement of dropins folder.
Previous Topic:Headless PDE build, missing required plug-ins!
Next Topic:Why is a .java file not an IFile?
Goto Forum:
  


Current Time: Mon Jul 07 17:05:58 EDT 2025

Powered by FUDForum. Page generated in 0.25284 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top