Community
Participate
Working Groups
I noticed a recent build failed, https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/juno.epp-repository-build/24/console due to [java] ERROR [0019] : No suitable provider for component org.eclipse.equinox.launcher.carbon.macosx:osgi.bundle(&(target.os=macosx)(target.ws=carbon)(|(target.arch=ppc)(target.arch=x86))) was found in resourceMap file:/opt/public/technology/epp/epp_repo/juno/org.eclipse.epp.allpackages.juno.feature/epp.rmap So, thought I'd mention that carbon fragments have been removed from platform for M2, and I removed them (sort of "early") from the "common repo" content. See comments in bug 352096. I could add it back if desired to "get a build" over next few days or week ... but ... M2 is only a week or two away at which time EPP would _have_ to change ... so, let me know if you do want them back temporarily.
Hmm, I am unable to find the reason, but maybe it has to do with the CQUERY properties in the epp-tp.cquery where we try to build the target platform. It contains the following properties: <cq:property key="target.arch" value="*"/> <cq:property key="target.os" value="*"/> <cq:property key="target.ws" value="*"/> My guess is that this is internally mapped to *all* platforms and Buckminster doesn't know about the change.
Thanks for investigating, Markus. I'm going to temporarily re-add the carbon configuration ... though I'd expect it to "break" once the platform contributes their M2. But adding it back now, might at least allow an EPP build to complete for a few days ... see if there are other issues. Let me know if/when anyone wants me to re-remove so this issue can be better investigated or fixed tested.
A very likely reason for this is that the org.eclipse.equinox.executable feature still references the missing fragments. As a workaround until bug 337334 has been addressed you can add explicit 'skip' nodes to your cquery.
(In reply to comment #3) > A very likely reason for this is that the org.eclipse.equinox.executable > feature still references the missing fragments. As a workaround until bug > 337334 has been addressed you can add explicit 'skip' nodes to your cquery. I'm not sure bug 337334 will be "fixed" ... and not sure how it's related to this issue, but ... assuming "skip" is still the way to go ... would that mean adding an "advisor node" to the cquery files, so it'd end up being: <?xml version="1.0" encoding="UTF-8"?><cq:componentQuery xmlns:cq="http://www.eclipse.org/buckminster/CQuery-1.0" resourceMap="epp.rmap"> <cq:rootRequest name="org.eclipse.platform" componentType="eclipse.feature"/> <cq:property key="target.arch" value="*"/> <cq:property key="target.os" value="*"/> <cq:property key="target.ws" value="*"/> <cq:advisorNode namePattern="org\.eclipse\.equinox\.launcher\.carbon\..*" componentType="osgi.bundle" skipComponent="true"/> </cq:componentQuery> (And, remember ... I know nothing about Buckminster ... I'm basing this on 30 minutes of googling and guessing.
The advice looks correct. I think that will do the trick.
There is less errors than in build 27, but sill, in build 31. https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/juno.epp-repository-build/31/console I guess I could "skip" org.eclipse.swt.carbon* and perhaps org.eclipse.ui.carbon* too? Seems it should not be "finding" these in meta data ... but, my guess, is perhaps it is because equinox is a "trusted repo" that it finds "old stuff" even though there is no "configuration" for it?
The next run, with those extra skip rules, actually had more errors, but seemed to get further ... this time also mentioning org.eclipse.epp.package.parallel.feature towards the end of run #32: https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/juno.epp-repository-build/32/console So, presumably they mention/require carbon explicitly?
Adding Beth and Greg to CC. Beth, and Greg, do you all have an explicit requirement for "carbon" platform in your builds/features? If so ... you'll need to remove it for Juno M2, as it will not be in the platform.
On a whim, I added the skip rules to epp.cquery as well. I am not sure of the difference between epp-tp.cquery and epp.query, but given their contents, seemed they both might need the rules. The subsequent run got much further, but still failed. Apparently different sorts of errors ... in fact, nothing was labled "error" but had tons of warnings about missing features, finally concluding with 40: Feature reference 'org.eclipse.jubula.feature' cannot be resolved [java] No component named org.eclipse.ui.carbon:osgi.bundle(&(target.os=macosx)(target.ws=carbon)) is known to Buckminster See https://hudson.eclipse.org/hudson/job/juno.epp-repository-build/33/console So ... I'm guess an announcement should go out to cross-project list to "warn" people to remove any dependencies/configs that expect 'carbon'?
The only reference to carbon in our org.eclipse.epp.package.parallel and feature project is in the epp.product file: <launcherArgs> ... <vmArgsMac>-XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts -XX:MaxPermSize=256m</vmArgsMac> Markus, do you know if that's it or if that's necessary I don't know of any requirements on carbon. Greg do you know of any?
(In reply to comment #6) > I guess I could "skip" > org.eclipse.swt.carbon* > and perhaps > org.eclipse.ui.carbon* > too? > Perhaps one node with a pattern like '\.carbon(\..+)?$' would be sufficient? I.e. skip everything that either ends with ".carbon" or contains ".carbon."
(In reply to comment #11) > (In reply to comment #6) > > I guess I could "skip" > > org.eclipse.swt.carbon* > > and perhaps > > org.eclipse.ui.carbon* > > too? > > > Perhaps one node with a pattern like '\.carbon(\..+)?$' would be sufficient? > I.e. skip everything that either ends with ".carbon" or contains ".carbon." It might ... but, I was trying a "minimal" approach ... just in case someone had a bundle named "...element.carbon" along with "..element.oxygen", etc. :)
(In reply to comment #11) > (In reply to comment #6) > > I guess I could "skip" > > org.eclipse.swt.carbon* > > and perhaps > > org.eclipse.ui.carbon* > > too? > > > Perhaps one node with a pattern like '\.carbon(\..+)?$' would be sufficient? > I.e. skip everything that either ends with ".carbon" or contains ".carbon." Looking though the content.xml for indigo release (from common repo) I also see some IU's named similar to toolingcarbon.macosx.x86org.eclipse.equinox.simpleconfigurator I'm betting those should skipped also?
(In reply to comment #13) > I'm betting those should skipped also? Those are generated at build time by the p2 publisher, so no, you don't need to worry about them.
After getting a "warmup" staging repo for M2 (that, should not have the platform's carbon support, any longer) the first package-repository build failed with https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/juno.epp-repository-build/39/console failed fast with [java] No component named org.eclipse.ui.carbon:osgi.bundle(&(target.os=macosx)(target.ws=carbon)) is known to Buckminster I think thought, maybe I need to back out my "skip" elements now, but the next build after that failed even "worse" pretty much like the original failure reported in comment #0. https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/juno.epp-repository-build/40/console So ... good thing Markus is back next week :)
Hmmm ... I just noticed, from looking at "multiple version" report, http://build.eclipse.org/juno/simrel/reports/nonUniqueVersions.txt that there are 3.x and 4.x versions of rcp, platform, in the Juno staging repository. (and, in the platform's M2 repository) Hence, I guess there is still "carbon" in the repositories so things have not changed as much I was assuming. So ... we will likely need the "skip" filters, at least, but then not sure why build 39 did not work ... I can not find target.ws=carbon anywhere in our scripts or metadata ... though, obviously, may not know where to look.
This appears no longer an issue in latest epp juno repository build, such as https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/juno.epp-repository-build/44/ was something "fixed" or, perhaps it was just a matter of something someone was contributing?
I am not yet convinced that it is resolved and will keep an eye on it. Over the weekend I updated the property that points to the correct p2 platform repository (platform.site=file:///home/data/httpd/download.eclipse.org/eclipse/updates/4.2milestones/S-4.2M2-201109161615) - this repo is used for building the target platform that is in turn used for compiling the EPP bundles. All other changes (e.g. the advisorNode) had been reverted before.
I'm not sure how to contribute to this issue. What can we do with Buckminster to improve the situation?
(In reply to comment #19) > I'm not sure how to contribute to this issue. What can we do with Buckminster > to improve the situation? By watching this bug... :) If the error occurs again, or if I find out more about it, I'll let you know.
The bug is currently a Buckminster/Core bug, perhaps it shouldn't be?
Moving to EPP... I don't want to close the bug right now.
The EPP project does not have its "own" Packager anymore. EPP uses other technologies, such as Eclipse Tycho, Maven and Eclipse PDE. Therefore any remaining bugs are now being closed as WONTFIX. If this bug is still relevant, please make a comment and we'll move it to the correct project/component for further investigation. This change was made as part of a bulk change.
