Recently I’m getting a bit confused about p2. There is an update site created with PDE headless build. There are IUs generated for each plug-in/fragment/feature. Everything looks great so far.
Let’s assume: plug-in A and fragment B with a defined host plug-in A are sitting together on single update site. Plug-in A in reality cannot run without appropriate version of fragment B (e.g. situation similar to SWT).
My understanding of p2-power was that I wouldn’t need to create separate feature C aggregating A and B just to make fragment B be automatically installed when I request installation of plug-in A.
I spent some time on reviewing Eclipse Bugzilla and mailing lists. Interesting findings:
http://wiki.eclipse.org/Equinox_p2_Meeting_2007#Fragments_optional_vs._requirement
https://bugs.eclipse.org/bugs/show_bug.cgi?id=256430
Any suggestions about handling such “required” fragment scenario without getting rid of autogenerated p2 repository and hand crafting p2 metadata?
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)
LikeLike
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.
LikeLike