Comments on: p2 and fragments http://urbas.tk/index.php/2009/05/18/p2-and-fragments/ Radoslaw H. Urbas homepage / blog Fri, 18 Jun 2010 20:10:51 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Radoslaw Urbas http://urbas.tk/index.php/2009/05/18/p2-and-fragments/comment-page-1/#comment-4343 Radoslaw Urbas Tue, 19 May 2009 14:22:23 +0000 http://urbas.tk/?p=110#comment-4343 Pascal - thanks for the information! Option #1 seems to meet my requirements. Now I'm trying to figure out how to integrate usage of org.eclipse.equinox.p2.publisher with PDE headless build. Pascal – thanks for the information! Option #1 seems to meet my requirements.
Now I’m trying to figure out how to integrate usage of org.eclipse.equinox.p2.publisher with PDE headless build.

]]> By: Pascal Rapicault http://urbas.tk/index.php/2009/05/18/p2-and-fragments/comment-page-1/#comment-4319 Pascal Rapicault Tue, 19 May 2009 00:05:12 +0000 http://urbas.tk/?p=110#comment-4319 There is no silver bullet here. p2 just can't guess whether a fragment must be installed for a given plug-in. Early on we had tried various heuristics but this is not something that never worked. The only correct solution lies in having the IU for your plug-in express something about the mandatory fragments. For this there are two possibilities: 1) The IU for the plug-in requires the IU of the fragments directly (using appropriate filters) 2) The IU for the plug-in requires a capability that will be provided by each fragment. The main difference between 1) and 2) lies in whether or not a new fragment can be contributed without changing the IU for the plug-in. Now, how to do this? In both case you will have to play with the p2.inf and make sure you use the publisher application (which replaces the metadata generator). To implement case #1, the plug-in will have to have a p2.inf that will declare the dependencies on the fragments For example: requires.1.namespace=org.eclipse.equinox.p2.iu requires.1.name=fragment.for.windows requires.1.filter=(os=win32) requires.1.greedy=true requires.1.range=[1.0.0, 2.0.0) For additional fragments, simply change the middle digit. To implement case #2, the fragments will each have to have a p2.inf indicating the capability they provide provides.1.namespace=my.plugin provides.1.name=implementation.provider provides.1.version=1.0.0 And the p2.inf for the plug-in will only have to have one requirement like the following one. requires.1.namespace=my.plugin requires.1.name=implementation.provider requires.1.filter=(os=win32) requires.1.greedy=true requires.1.range=[1.0.0, 2.0.0) There is no silver bullet here. p2 just can’t guess whether a fragment must be installed for a given plug-in. Early on we had tried various heuristics but this is not something that never worked. The only correct solution lies in having the IU for your plug-in express something about the mandatory fragments. For this there are two possibilities:
1) The IU for the plug-in requires the IU of the fragments directly (using appropriate filters)
2) The IU for the plug-in requires a capability that will be provided by each fragment.
The main difference between 1) and 2) lies in whether or not a new fragment can be contributed without changing the IU for the plug-in.
Now, how to do this? In both case you will have to play with the p2.inf and make sure you use the publisher application (which replaces the metadata generator).
To implement case #1, the plug-in will have to have a p2.inf that will declare the dependencies on the fragments
For example:
requires.1.namespace=org.eclipse.equinox.p2.iu
requires.1.name=fragment.for.windows
requires.1.filter=(os=win32)
requires.1.greedy=true
requires.1.range=[1.0.0, 2.0.0)

For additional fragments, simply change the middle digit.

To implement case #2, the fragments will each have to have a p2.inf indicating the capability they provide
provides.1.namespace=my.plugin
provides.1.name=implementation.provider
provides.1.version=1.0.0

And the p2.inf for the plug-in will only have to have one requirement like the following one.
requires.1.namespace=my.plugin
requires.1.name=implementation.provider
requires.1.filter=(os=win32)
requires.1.greedy=true
requires.1.range=[1.0.0, 2.0.0)

]]>