Community
Participate
Working Groups
Build Identifier: M20110909-1335 During resolution, the CSpecGenerator for bundles does not create the bin.includes attribute if the component is not stored locally on the file system but in a version control system (e.g.). This fact lets resolution fail on plug-ins which alter the bin.includes attribute in a CSPEX because, the altered attribute is missing: org.knime.ext.sun:osgi.bundle: Resolution attempt ended with exception: CSpec org.knime.ext.sun has no action, group, or local artifact named bin.includes Everything works fine, if the very same plug-in is already present in the file system. Also in Eclipse 3.6 this used to work. The reasons seems to be a change in CSpecFromSource#generate between the release for 3.6 and 3.7. In lines 292ff the new version explicitly sets the bin.includes to an empty list, if the used reader is not a file system reader: if (getReader().isFileSystemReader()) { File baseDir = getReader().getLocation(); binIncludes = expandBinFiles(baseDir, build); srcIncludes = expandSrcFiles(baseDir, build); } else { binIncludes = Collections.emptyList(); srcIncludes = Collections.emptyList(); } Subsequently the attribute is not added to the generated CSPEC and altering this attribute finally leads to the above error message. Reproducible: Always Steps to Reproduce: 1. add a CSPEX to a bundle that alters the bin.includes attribute 2. try to resolve this bundle from a remote version control system (e.g. Subversion)
*** Bug 387351 has been marked as a duplicate of this bug. ***
Detailed (and easier) instructions on how to reproduce the problem can be found in the duplicate bug #387351.
Created attachment 221016 [details] Patch for CSpec generation classes This patch partially restores the previous behaviour, where bin.includes and src.includes are evaluated and added to the generated CSpec even if the components are not on the local file system. Currently bin.includes are not added to the CSpec if read from e.g. SVN and therefore any attempt to modify this artifact via a CSpex fails during resolution. It's probably not the nicest way to fix this problem, but at least it works. If this could be added to Indigo maintenance we would finally be able to switch from 3.6 to 3.7 or above.
Created attachment 245827 [details] Patch for CSpec generation classes (for BM 4.4) Any chances this can be integrated into the official Buckminster release? I just tried the official build and the problems is still there. Fortunately the same patch from two years ago still works (with minor) modifications. We just don't want to use a patched version of BM in our group for the next 10 years...
I finally managed to sign the CLA, so it should be safe to include the patch. Some pieces of the patch come from old Buckminster code (just restoring the previous behaviour as I've written in one of the previous see Comment #3), so I cannot really say that the code is 100% mine (as per the "Certificate of Origin"). But everything is either older Buckminster code or is solely contributed by myself and complies with the CoO.
Patch applied in commit http://git.eclipse.org/c/buckminster/buckminster.git/commit/?id=c212f822a7baeb83d4f65c700863e932be68e955 Thanks. A new build is underway and will be available in our repositories within an hour.
