Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    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
michael.sacarny is currently offline michael.sacarny
Messages: 103
Registered: July 2009
Location: USA
Senior Member
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
Andrew Niefer is currently offline Andrew Niefer
Messages: 990
Registered: July 2009
Senior Member
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
michael.sacarny is currently offline michael.sacarny
Messages: 103
Registered: July 2009
Location: USA
Senior Member
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
michael.sacarny is currently offline michael.sacarny
Messages: 103
Registered: July 2009
Location: USA
Senior Member
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]

Report message to a 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
michael.sacarny is currently offline michael.sacarny
Messages: 103
Registered: July 2009
Location: USA
Senior Member
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
michael.sacarny is currently offline michael.sacarny
Messages: 103
Registered: July 2009
Location: USA
Senior Member
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
michael.sacarny is currently offline michael.sacarny
Messages: 103
Registered: July 2009
Location: USA
Senior Member
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
michael.sacarny is currently offline michael.sacarny
Messages: 103
Registered: July 2009
Location: USA
Senior Member
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: Thu Jul 31 15:51:08 EDT 2014

Powered by FUDForum. Page generated in 0.01756 seconds