Hi Brian, Thanks a lot for your detailed explanation and for the proposal! I tried it the way you proposed:
1) Removed the feature from my update.product file 2) Created update.p2.inf file in project's root directory (I'm using tycho) with this content: requires.1.namespace = org.eclipse.equinox.p2.iu requires.1.name = update.feature.feature.group requires.1.range = (1.0.0, 2.0.0) After I ran the build my repository just contained content.xml, artifacts.xml and one file in the binaries directory. It is missing the feature jar and the three plugin jars. I tried to put the p2.inf file in the META-INF directory, but the result was similar. I ran tycho in debug mode, but the output did not say much what the reasons for adding some files and not adding others are. I even tried to change the version ranges, but no luck. Am I doing anything wrong? Thanks, Ivan On Thu, Aug 4, 2011 at 5:32 PM, Brian de Alwis <[email protected]>wrote: > Hi Ivan. > > 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: > > > 1. Products are singletons: only a single version can be installed — > you can't have multiple versions of a product installed at the same time > 2. Your product is specifically requiring a particular version of your > feature (say version X), which is in turn requiring particular versions of > various bundles. > 3. 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. > > Brian. > > On 3-Aug-2011, at 11:04 AM, Ivan St. Ivanov wrote: > > Hi Brian, > > 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. > > However, I feel confused as besides the lack of that special plugin.xml my > product looks quite similar to the one under > http://dev.eclipse.org/viewcvs/viewvc.cgi/pde-build-home/examples/adt.feature.builder/ > > So could you please advise me where should I start from? > > Thanks, > Ivan > > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev > > > > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev > >
_______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
