Bugzilla – Full Text Bug Listing
| Summary: | regression : "No component named XX is known to Buckminster" | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Nicolas Bros <nicolas.bros> |
| Component: | Buckminster | Assignee: | buckminster.core-inbox <buckminster.core-inbox> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | thomas |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Nicolas Bros
(In reply to comment #0) > I fixed the errors by adding the bundles Buckminster couldn't find to the > cspec, one by one, but this is very laborious, and I think Buckminster should > be able to resolve the dependencies itself. > I don't fully understand what you mean. What cspec did you add them to? Buckminster doesn't perform resolution during site.p2 so in what way should Buckminster be able to resolve? Do you mean during import? Can you see between what [start] and [end] tags the messages are printed? (In reply to comment #1) > What cspec did you add them to? To the cspec in my releng project. > Buckminster doesn't perform resolution during site.p2 so in what way should > Buckminster be able to resolve? Do you mean during import? I don't fully understand how Buckminster works, but what I know is that it worked before and doesn't work with the integration version. > Can you see between what [start] and [end] tags the messages are printed? after [start org.eclipse.gmt.modisco.all:eclipse.feature$0.9.0.qualifier#site.p2] The end of the build: INFO: [end org.eclipse.gmt.modisco.all:eclipse.feature$0.9.0.qualifier#site.signed] INFO: [start org.eclipse.gmt.modisco.all:eclipse.feature$0.9.0.qualifier#site.packed] INFO: [end org.eclipse.gmt.modisco.all:eclipse.feature$0.9.0.qualifier#site.packed] INFO: [start org.eclipse.gmt.modisco.all:eclipse.feature$0.9.0.qualifier#manifest] INFO: [end org.eclipse.gmt.modisco.all:eclipse.feature$0.9.0.qualifier#manifest] INFO: [start org.eclipse.gmt.modisco.all:eclipse.feature$0.9.0.qualifier#site.p2] No component named org.eclipse.emf.compare:osgi.bundle is known to Buckminster Does any of the features that are included in the final update site include the missing bundles? Another question before I try your build from scratch. Did you run this on a fresh workspace or could this be the result of some older import? > Does any of the features that are included in the final update site include the missing bundles? No, MoDisco features only include other MoDisco features > Did you run this on a fresh workspace or could this be the result of some older import? The build was run on a fresh workspace and target platform. Btw, if you want to test the build, please remove the dependencies from the cspec, that I added as a workaround: <cs:dependency name="org.eclipse.emf.sdk" componentType="eclipse.feature"/> <cs:dependency name="org.eclipse.acceleo.sdk" componentType="eclipse.feature"/> <cs:dependency name="org.eclipse.m2m.atl.sdk" componentType="eclipse.feature"/> <cs:dependency name="org.eclipse.uml2.sdk" componentType="eclipse.feature"/> <cs:dependency name="org.eclipse.m2m.atl.dsls" componentType="osgi.bundle"/> <cs:dependency name="org.antlr.runtime" componentType="osgi.bundle"/> <cs:dependency name="org.eclipse.emf.compare" componentType="osgi.bundle"/> <cs:dependency name="org.eclipse.jet.core" componentType="osgi.bundle"/> This does not seem to be a regression after all, it's more likely that it is related to the selection/order of the p2 repositories used in the RMAP when resolving the p2 platform. I'm marking this as a duplicate of the now reopened bug 322506 where a more elaborate explanation can be found. *** This bug has been marked as a duplicate of bug 322506 *** |