Community
Participate
Working Groups
The Papyrus features are organized like this : org.eclipse.papyrus.build.feature org.eclipse.papyrus.sdk.feature org.eclipse.papyrus.xxx.feature org.eclipse.papyrus.yyy.feature org.eclipse.papyrus.sdk.sources.feature org.eclipse.papyrus.xxx.source.feature org.eclipse.papyrus.yyy.source.feature When building Papyrus with the root feature (o.e.p.build.feature) that contains only o.e.p.sdk.feature but not o.e.p.sdk.sources.feature, the build succeeds. But when building Papyrus with the root feature that contains both o.e.p.sdk.feature and o.e.p.sdk.sources.feature, the build fails apparently because Buckminster can't find org.eclipse.papyrus.customization.palette, which is a fragment. We tried isolating the fragment in a separate feature that is not in o.e.p.sdk.sources.feature, but it does not work either. So, I suspect there is a bug in Buckminster related to the handling of fragments. Here is the exception : [java] org.eclipse.buckminster.core.metadata.MissingComponentException: No component named org.eclipse.papyrus.customization.palette:osgi.bundle/[0.9.0.v201201101602,0.9.0.v201201101602] is known to Buckminster [java] at org.eclipse.buckminster.core.metadata.WorkspaceInfo.resolveLocal(WorkspaceInfo.java:613) [java] at org.eclipse.buckminster.core.metadata.WorkspaceInfo.getResolution(WorkspaceInfo.java:504) [java] at org.eclipse.buckminster.core.metadata.ModelCache.findCSpec(ModelCache.java:48) [java] at org.eclipse.buckminster.core.cspec.model.CSpec.getReferencedCSpec(CSpec.java:470) [java] at org.eclipse.buckminster.core.cspec.model.CSpec.getReferencedAttribute(CSpec.java:448) [java] at org.eclipse.buckminster.core.cspec.model.Prerequisite.getReferencedAttribute(Prerequisite.java:146) [java] at org.eclipse.buckminster.core.internal.actor.PerformManager.addAttributeChildren(PerformManager.java:327) [java] at org.eclipse.buckminster.core.internal.actor.PerformManager.getOrderedActionList(PerformManager.java:414) [java] at org.eclipse.buckminster.core.internal.actor.PerformManager.internalPerform(PerformManager.java:435) [java] at org.eclipse.buckminster.core.internal.actor.PerformManager.access$0(PerformManager.java:430) [java] at org.eclipse.buckminster.core.internal.actor.PerformManager$DeferredActionInvocation.execute(PerformManager.java:93) [java] at org.eclipse.buckminster.core.internal.actor.PerformManager.internalPerform(PerformManager.java:454) [java] at org.eclipse.buckminster.core.internal.actor.PerformManager.perform(PerformManager.java:293) [java] at org.eclipse.buckminster.core.internal.actor.PerformManager.perform(PerformManager.java:305) [java] at org.eclipse.buckminster.core.commands.Perform.internalRun(Perform.java:108) [java] at org.eclipse.buckminster.core.commands.WorkspaceCommand.run(WorkspaceCommand.java:91) [java] at org.eclipse.buckminster.cmdline.AbstractCommand.basicRun(AbstractCommand.java:200) [java] at org.eclipse.buckminster.cmdline.Headless.run(Headless.java:350) [java] at org.eclipse.buckminster.cmdline.Headless.run(Headless.java:145) [java] at org.eclipse.buckminster.cmdline.Headless.start(Headless.java:165) [java] at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) [java] at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) [java] at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) [java] at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) [java] at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [java] at java.lang.reflect.Method.invoke(Method.java:592) [java] at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) [java] at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) [java] at org.eclipse.equinox.launcher.Main.run(Main.java:1410) [java] at org.eclipse.equinox.launcher.Main.main(Main.java:1386) [java] No component named org.eclipse.papyrus.customization.palette:osgi.bundle/[0.9.0.v201201101602,0.9.0.v201201101602] is known to Buckminster [java] Java Result: 1
Created attachment 209270 [details] The build log The build log
(In reply to comment #1) > Created attachment 209270 [details] > The build log > > The build log Hello Vincent, have you found a solution for this? Seems like I have the same issue. #feature.jar action runs without exceptions, but #source.feature.jar logs No component named <my fragment> is known to Buckminster
(In reply to comment #2) Hi Dennis, I'm sorry but I did find a solution for this bug...
(In reply to comment #3) > (In reply to comment #2) > Hi Dennis, > I'm sorry but I did find a solution for this bug... I found some strange workaround. If I set the fragment version to something static (without qualifier) buckminster resolves the fragment. Would you please set your fragment version to 0.9.0.v1 and try to build? Say if it works for you.
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > Hi Dennis, > > I'm sorry but I did find a solution for this bug... > > I found some strange workaround. If I set the fragment version to something > static (without qualifier) buckminster resolves the fragment. > Would you please set your fragment version to 0.9.0.v1 and try to build? Say if > it works for you. Hello Denis, you are right. It works fine when you replace 0.9.0.qualified by 0.9.0.v1. Thank you for the workaround.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > (In reply to comment #2) > > > Hi Dennis, > > > I'm sorry but I did find a solution for this bug... > > > > I found some strange workaround. If I set the fragment version to something > > static (without qualifier) buckminster resolves the fragment. > > Would you please set your fragment version to 0.9.0.v1 and try to build? Say if > > it works for you. > > Hello Denis, you are right. It works fine when you replace 0.9.0.qualified by > 0.9.0.v1. Thank you for the workaround. Looks like a real bug to me. Is there any chance to get it fixed?
Seems to be the same problem as in 330088
Created attachment 211116 [details] An example project set: releng/features/plugin/fragment Please look into generated source feature manifest.(e.g. under output/de.dhuebner.buckytest.feature_1.0.0-eclipse.feature/temp/source/feature.xml) it contains both fragment and fragment.source entry: <plugin id="de.dhuebner.buckytest.fragment.source" download-size="0" install-size="0" version="1.0.0.v201202161525" unpack="false"/> <plugin id="de.dhuebner.buckytest.fragment" download-size="0" install-size="0" version="1.0.0.v201202161525" fragment="true" unpack="false"/> ... which is not desired. It's also does'n matter in which feature the fragment lives if the fragment is in buckminster scope it will be added to the host bundle's source feature. Unfortunately this example does not reproduces the MissingComponentException, I think because the build qualifier somehow matches in this case. See workaround in previous comment.
I debugged a bit and found corresponding group in: org.eclipse.buckminster.pde.cspecgen.bundle.CSpecFromSource.generate(IProgressMonitor) Line:560 cspec.addGroup(ATTRIBUTE_BUNDLE_AND_FRAGMENTS_SOURCE, true); This entry should run target.fragments.source action which should copy the fragment's source.jar to the ${buckminster.output}/fragments folder, but it never happens, I think because there is already the binary jar in. So this ${buckminster.output}/fragments folder is reused as a prerequisite of the bundle.and.fragments.source group, which cause that the binary fragment entry is inserted in the source feature's manifest.
Created attachment 211176 [details] Test case that indicates the undesired source feature.xml entry
Created attachment 211183 [details] HQ Patch that fixes at least this bug Attribute bundle.and.fragments.source: Setting product's base to e.g. source.fragments instead of fragmants solves the problem. I think it generally intended to separate binary and sourcejars, like it already happens for the regular bundle jars (jar, source.jar). Hopefully these changes don't break something. I tried to launch /org.eclipse.buckminster.tests/AllTests.launch but became 3 errors and 3 failures of 37 runs before my changes.
I can confirm that this is still a bug, but the workaround is not working for me.
Juhu! https://hudson.eclipse.org/hudson/job/buckminster-head/178/testReport/org.eclipse.buckminster.tests.AllTests$org.eclipse.buckminster.pde.test.AllTests$org.eclipse.buckminster.pde.test/SourceFeatureTest/
Sorry for being so slow on this one. *** This bug has been marked as a duplicate of bug 330088 ***
