I wouldn't say I'm a p2 expert yet, but I've spent enough time working through the same problems. I too had difficulty grokking p2's model and why I couldn't update a particular item. So I hope you don't mind if I back up and do a quick overview. (Well, maybe not so quick. But I hope it helps.)
p2 identifies a set of things called artifacts; typical examples are a product, feature, or a bundle (aka plugin). A particular artifact is uniquely identified by an identifier and a version. p2 assumes that two artifacts with the same identifier and version are identical.
p2 allows specifying requirements between artifacts; this information is captured in an installable unit (or IU). p2 itself allows specifying these requirements with version ranges, though a requirement can be expressed such that it only applies to exactly one version.
As part of a build, PDE/Build, Tycho, and other build tools offer to "publish" the results of the build into a p2 repository. This means transforming the metadata from the various bundle MANIFEST.MF, feature.xml and .product files into appropriate requirements for p2.
Although p2 itself allows specifying requirements with version ranges, the original definitions of the feature.xml and .product files require specifying an exact version. So a feature points to exact versions of its bundles, and a product points to exact versions of its constituent features or plugins.
Finally some artifacts can be marked as being singletons. A singleton artifact cannot be installed alongside another artifact with the same id but different version.
The problem you're encountering is that:
- Products are singletons: only a single version can be installed — you can't have multiple versions of a product installed at the same time
- Your product is specifically requiring a particular version of your feature (say version X), which is in turn requiring particular versions of various bundles.
- And I'd hazard that at least some of these bundles in your feature are singletons, likely because they use extension points.
#3 means that trying to install your updated feature (version Y) alongside version X will fail since several bundles are singletons and can't be installed simultaneously. #2 means you can't update the feature (remove version X and replace it with version Y) since the product requires exactly X.
The p2.inf approach described by Andrew changes the product from specifying an exact feature version requirement to a version range, thus allowing replacing version X to version Y to work. The p2.inf file provides p2-specific information when the .product file is published. **Note** this approach requires removing the feature from the .product file — the feature is now specified through the p2.inf. And the p2.inf must be alongside the .product file; the exact form depends on your build tool (e.g., PDE/Build requires it to be in the same directory as the .product file and simply called p2.inf; Tycho requires it to be called X.p2.inf for X.product).
There's also an alternative: update the product instead of just a particular feature.
On 3-Aug-2011, at 11:04 AM, Ivan St. Ivanov wrote:
Thanks for your answer!
I had to start my question with the note that I am far from being a p2/PDE expert. So I read your answer and the two blogs very carefully for several times. I even tried to read the comments of the second article. And still can't figure out how can I work around the issue
Here is what I got:
1) The RCP app which feature I am trying to update has declared a versioned dependency on the 'update' feature
2) I come with a product that contains newer version of that feature
3) p2 complains about that
There are two possible solutions for the issue: by using p2.inf file to specify my feature's dependencies or by creating a special plugin.xml along one of my plugins.
So could you please advise me where should I start from?