Community
Participate
Working Groups
Build Identifier: 3.6.0.v3650b When I try to use buckminster and p2 to resolve the feature org.eclipse.rcp I get errors related to resolving platform-specific fragments of org.eclipse.swt. [java] ERROR [0055] : No suitable provider for component org.eclipse.swt.photon.qnx.x86:osgi.bundle/[3.6.0.v3650b,3.6.0.v3650b](&(target.arch=x86)(target.os=qnx)(target.ws=photon)) was found in searchPath helios [java] ERROR [0055] : Rejecting provider p2(http://download.eclipse.org/releases/helios[http://download.eclipse.org/releases/helios]): No component match was found [java] ERROR [0055] : No suitable provider for component org.eclipse.swt.motif.solaris.sparc:osgi.bundle/[3.6.0.v3650b,3.6.0.v3650b](&(target.arch=sparc)(target.os=solaris)(target.ws=motif)) was found in searchPath helios [java] ERROR [0055] : Rejecting provider p2(http://download.eclipse.org/releases/helios[http://download.eclipse.org/releases/helios]): No component match was found Basically, every fragment of org.eclispe.swt is included in the feature. Since we don't have these in the p2 repo, we can't resolve the feature. It would be nice if p2 didn't error out unless we actually were missing fragments that are applicable to our current platform, but in the mean time we should either get the missing fragments into the p2 repo, or get them out of org.eclipse.rcp. Note that this problem breaks all the build systems that rely on buckminster/p2 to materialize a target platform. Reproducible: Always Steps to Reproduce: Run Buckminster to using an importtargetdefinition and an import of the org.eclipse.rcp feature against an rmap containing http://download.eclipse.org/releases/helios
I think this is buckminster complaining. The feature entries for these fragments should all be protected with platform specific filters.
That's true, they are marked correctly with the filters. They should still be present in the p2 repo though. What's the point of having a feature that references fragments that don't exist? :) Ideally Buckminster would be a little smarter about not failing when we really didn't need the dependencies, but I think the primary problem is the fact that the fragments aren't in the repo. If that part of the situation needs to be solved by someone else, I'd appreciate any help forwarding this bug on to them. In the mean time if this is going to take a while I'd sure appreciate any workaround you guys might have up your sleeve.
(In reply to comment #2) > Ideally Buckminster would be a little smarter about not failing when we really > didn't need the dependencies, but I think the primary problem is the fact that > the fragments aren't in the repo. > Define "really didn't need" please. My guess is that your objective is to build a p2 repository and that you want this p2 repository to serve as base for the application that uses RCP. In essence, you want the p2 repository to be platform agnostic and serve anyone who'd like to install from it. Buckminster achieves this goal by including everything that the features include, regardless of platform filtering (you use target.os=*, target.ws=*, target.arch=*). The alternative would be to specify each and every platform that you'd like to provide in the result. The fragments in question can be found in the platform repository so if you include the http://download.eclipse.org/eclipse/updates/3.6 in your rmap, Buckminster will be happy. Another option is to add advisor nodes with a 'skip' rule in the cquery for the fragments in question. Helios doesn't include them (unfortunately) since there is no corresponding Eclipse distribution. We should fix that. > If that part of the situation needs to be solved by someone else, I'd > appreciate any help forwarding this bug on to them. > Consider the bug forwarded. I'm reopening bug 312011. > In the mean time if this is going to take a while I'd sure appreciate any > workaround you guys might have up your sleeve. Workarounds mentioned above. Include the platform repository in your rmap or add skip rules to your cquery.
(In reply to comment #2) > That's true, they are marked correctly with the filters. They should still be > present in the p2 repo though. What's the point of having a feature that > references fragments that don't exist? :) This has come up before, see for example bug 135604 comment #13. org.eclipse.rcp (and org.eclipse.equinox.executable) can be used by other companies building products for platforms that we do not build ourselves.
(In reply to comment #4) > (In reply to comment #2) > > That's true, they are marked correctly with the filters. They should still be > > present in the p2 repo though. What's the point of having a feature that > > references fragments that don't exist? :) > > This has come up before, see for example bug 135604 comment #13. > org.eclipse.rcp (and org.eclipse.equinox.executable) can be used by other > companies building products for platforms that we do not build ourselves. That argument is valid as long as the fragments in question can be obtained from eclipse.org. If not, then our position must be that those companies should provide their own features. After all, how hard can it be to to create a feature that includes the org.eclipse.rcp feature and then adds proprietary fragments? An approach where we provide features that includes fragments that are otherwise unavailable makes no sense at all. What criteria is used for inclusion of those features? That IBM needs them?
(In reply to comment #3) > Define "really didn't need" please. Fair question. I retract my previous statement. I guess Buckminster has every right to bomb out on that one.
(In reply to comment #4) > This has come up before, see for example bug 135604 comment #13. Andrew, this seems to be the wrong bug. It's about javadoc...
Sorry, bug 135804
(In reply to comment #8) > Sorry, bug 135804 Ah, OK. I think that one is obsoleted by bug 213437. Since then, a regression was introduced in 3.6 and now we have bug 319345. This bug is handled internally by Buckminster (kind of dirty, but there's no obvious workaround since the fragments in question is nowhere to be found).
(In reply to comment #9) > (In reply to comment #8) > > Sorry, bug 135804 > > Ah, OK. I think that one is obsoleted by bug 213437. Since then, a regression > was introduced in 3.6 and now we have bug 319345. This bug is handled > internally by Buckminster (kind of dirty, but there's no obvious workaround > since the fragments in question is nowhere to be found). I don't know why I didn't find 213437 in my search. I knew this had come up before, I just didn't know what the resolution was
(In reply to comment #3) > The fragments in question can be found in the platform repository so if you > include the http://download.eclipse.org/eclipse/updates/3.6 in your rmap, > Buckminster will be happy. This solution is working for me. Thanks for the help.
Closing this since it's no longer a problem.
(In reply to comment #12) > Closing this since it's no longer a problem. I should clarify: the workaround is working for me. It would still be a good idea to get these fragments into the helios repository though. Is anyone working on that part of this issue?
