Bugzilla – Full Text Bug Listing
| Summary: | "No suitable provider" for sparcv9 | ||
|---|---|---|---|
| Product: | Community | Reporter: | David Williams <david_williams> |
| Component: | Cross-Project | Assignee: | David Williams <david_williams> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | daniel_megert, john.arthorne, michael.wenz, Mike_Wilson, thomas, tjwatson |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 396816 | ||
|
Description
David Williams
Message on cross-project list: http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg08391.html Ok, here's what I did:
I tried to get an M4 build for Graphiti to enable WTP consuming it for M4. The issue we had was the wrong ICU4J dependencies we inherit from our dependencies (GEF and EMF Transactions, but this shouldn't matter).
I updated my dependencies to their latest integration builds so their ICU dependencies are right for M4. I can build that based on the Eclipse platform update site for M3.
But in order to get the dependencies right for the Graphiti update site, I need to consume the right ICU version in my Graphiti build (Buckminster based). So I tried switching to the latest Eclipse platform integration build (I20121214-0730). As soon as I did that I get a build error that a sparcv9 filesystem bundle cannot be resolved:
ERROR [0053] : No suitable provider for component org.eclipse.core.filesystem.solaris.sparcv9:osgi.bundle(&(target.arch=sparcv9)(target.os=solaris)) was found in resourceMap file:/opt/users/hudsonbuild/.hudson/jobs/gmp-graphiti-nightly/workspace/org.eclipse.gmp/org.eclipse.gmp.graphiti/releng/org.eclipse.graphiti.releng/build.rmap
ERROR [0053] : No suitable provider for component org.eclipse.core.filesystem.solaris.sparcv9:osgi.bundle(&(target.arch=sparcv9)(target.os=solaris)) was found in searchPath binaries.platform
ERROR [0053] : Rejecting provider p2({0}/eclipse/updates/4.3-I-builds[file:/home/data/httpd/download.eclipse.org/eclipse/updates/4.3-I-builds]): No component match was found
Adding Thomas, as maybe he can help answer the Buckminster part of the question. Thomas, we in the platform added a few new filesystem fragments in M4. Is there something Buckminster consumers need to do differently? Anything for a work around, if not fix. They especially may need a "work around" if I in the platform packaged something wrong. Michael, I don't know enough about Buckminster to be of much direct help, But my guess is if you have some "wild cards" in the rmap, (match everything) then perhaps you can try limiting the architectures you support? Do you have any platform specific code? Perhaps try specifying just one, and see if that works? Thomas, I tried adding "sparcv9" to the aggregation file ... I just wanted to test/confirm our platform contribution would still validate. I'm not sure that is at all the right thing to do, but trying it, I get "invalid value" and the editor won't open, thinking that an invalid model. So, does the Aggregator need the value added to its EMF model? Or, am I just completely off-base? (In reply to comment #3) > Michael, I don't know enough about Buckminster to be of much direct help, > But my guess is if you have some "wild cards" in the rmap, (match > everything) then perhaps you can try limiting the architectures you support? > Do you have any platform specific code? Perhaps try specifying just one, and > see if that works? Yes, I think we are using wildcards and I can try to exclude sparcv9. But I'm not sure if I will get to that today. And no, we are having no platform specific coding. I defined a target.os restriction for my build and now it runs a step further. It seems as if this will help but it needs some fine tuning, because I now get a later error (now not in the resoltion step but in the actual compile phase) regarding SWT stuff not being resolvable. It seems as if my os restriction is too limited... Short update: After some trial and error I was able to produce a first M4 milestone build for Graphiti based on this workaround That's good to hear, Michael. I'd like to confirm that "sparcv9" is a valid "architecture" value for us to be using. Adding Tom Watson for his expertise; Tom, is "sparcv9" valid? It is listed in one of our file-system fragments that was new in M4. (bug 394297) I do not see where sparcv9 is not listed in org.eclipse.osgi.service.environment.Constants but assume that's not an exhaustive list, just the most popular/common? Should a new bug be open to consider adding it? Corollary question, we do not provide a launcher for "sparcv9" (that I could see) so how does someone make use of a sparcv9 file-system fragment? Is there some relationship built in, so that a "sparc" launcher works on "sparcv9" and just "figures out" if it needs the "sparc" or "sparcv9" file-system fragment? If "sparcv9" is not valid, what is the right value? In the fragment itself, in our source repostirory, I see Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: %fragmentName Bundle-SymbolicName: org.eclipse.core.filesystem.solaris.sparcv9;singleton:=true Bundle-Version: 1.1.0.qualifier Bundle-Vendor: %providerName Fragment-Host: org.eclipse.core.filesystem;bundle-version="[1.3.0,2.0.0)" Bundle-Localization: fragment Eclipse-PlatformFilter: (& (osgi.os=solaris) (osgi.arch=sparcv9)) But, in looking at our M4 repository, I do not see is listed on file system (but do see two new ones, compared to M3). Have I merely forgotten to include it in the repository? M4: *filesystem*jar org.eclipse.core.filesystem_1.4.0.v20121214-093840.jar org.eclipse.core.filesystem.source_1.4.0.v20121214-093840.jar org.eclipse.core.filesystem.aix.ppc_1.1.0.v20120913-140028.jar * org.eclipse.core.filesystem.aix.ppc64_1.1.0.v20120913-140028.jar * org.eclipse.core.filesystem.hpux.ia64_1.1.0.v20121109-195916.jar org.eclipse.core.filesystem.linux.x86_1.4.0.v20120522-1137.jar org.eclipse.core.filesystem.linux.x86_64_1.2.0.v20120522-1137.jar org.eclipse.core.filesystem.macosx_1.3.0.v20120522-1137.jar org.eclipse.core.filesystem.solaris.sparc_1.2.0.v20120913-140028.jar org.eclipse.core.filesystem.win32.x86_1.4.0.v20121112-094809.jar org.eclipse.core.filesystem.win32.x86_64_1.4.0.v20121112-135758.jar M3: *filesystem*jar org.eclipse.core.filesystem_1.3.200.v20121005-141300.jar org.eclipse.core.filesystem.source_1.3.200.v20121005-141300.jar org.eclipse.core.filesystem.aix.ppc_1.1.0.v20120913-140028.jar org.eclipse.core.filesystem.linux.x86_1.4.0.v20120522-1137.jar org.eclipse.core.filesystem.linux.x86_64_1.2.0.v20120522-1137.jar org.eclipse.core.filesystem.macosx_1.3.0.v20120522-1137.jar org.eclipse.core.filesystem.solaris.sparc_1.2.0.v20120913-140028.jar org.eclipse.core.filesystem.win32.x86_1.1.300.v20121005-141300.jar org.eclipse.core.filesystem.win32.x86_64_1.1.300.v20120522-1137.jar Thanks for any information to help get this solved in a general, correct way. I'm not sure we did the right thing by adding "sparcv9" in our build. The AIX 64-bit platform that we added in bug 394297 is actually an architecture we build the platform for. We only build one SPARC download, so having both "sparc" and "sparcv9" doesn't sound right. I'm trying to track down the original contributors of this fragment to figure out the story here. It turns out sparcv9 is the os value given by the JVM when running on 64-bit sparc. This is not a platform that the Equinox framework or launcher have ever been built for (although maybe something valid to add in the future). In the meantime I suggest we treat it the same was as platforms like os390 in our build.. that is to say, not building it. (In reply to comment #9) > It turns out sparcv9 is the os value given by the JVM when running on 64-bit > sparc. This is not a platform that the Equinox framework or launcher have > ever been built for (although maybe something valid to add in the future). > In the meantime I suggest we treat it the same was as platforms like os390 > in our build.. that is to say, not building it. Thanks John, I've reopened bug 394297 so at this moment our plan will be to remove the sparcv9 file-system fragment that was added via that bug. As a purely incidental side-effect, I've also opened an enhancement request, bug 396778, to add more configuration values to the b3 aggregator (though that's just something I happened to learn while looking at this bug, not really related to it). I'm going to mark this as fixed because, via bug 394297, I have removed the sparcv9 fragment hastily added for M4, so should be gone by 1/1 I-build (and M5). (In reply to comment #11) Just as a short update: I switched to that 1/1 I-build and was able to remove my platform filters in the build again. Works as expected and as before again. Thanks, Michael |