Community
Participate
Working Groups
My product had a plugin, the owners of which sought to have packaged as a single JAR. They made appropriate changes to its build.properties > jars.compile.order = . > bin.includes = META-INF/,\ > icons/,\ > lib/,\ > plugin.properties,\ > plugin.xml,\ > . > src.includes = eistools/,\ > schema/,\ > templates/ > source.. = eistools/ > output.. = bin/ but failed to remove > Bundle-ClassPath: eistools.jar, > lib/wpai.mediators.command.jar from their MANIFEST.MF. As a result, during the build, 0 the plugin gets checked out (along with the rest) 1 PDEB generates the plugin's build.xml with "." in place of "@dot" 2 the plugin is subsequently deleted (presumably by the malformed target=clean) 3 the build continues until failing with log error like > Basedir /path/to/pde-build/plugins/name.of.plugin does not exist The fix in this case, was to revert to a directory-based plugin by build.properties ~= s/./nameOfPlugin.jar. (Presumably removing property=Bundle-ClassPath from MANIFEST.MF would also work.) The plugin was in fact malformed, but PDEB's response was just as certainly wrong: the build should not delete the plugin and then fail with a misleading error message. Deleting the plugin is the worst part, since it makes debugging the problem much harder.
Yep that's annoying. We will investigate. Note that since last week's build PDE UI validates build.properties and should capture this kind of errors.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=125432#c1 > Note that since last week's build PDE UI validates build.properties > and should capture this kind of errors. Hopefully CCB will step up to M5 soonest. One more thing to make a testcase for: another user created com.ibm.etools.tui.ui/build.properties > jars.compile.order = . > source... = src/ > output... = bin/ > bin.includes = .,\ > plugin.xml,\ > META-INF/ > src.includes = src/,\ > schema/,\ > plugin.xml,\ > plugin.properties,\ > images/,\ > build.properties,\ > .template,\ > .project,\ > .options,\ > .classpath which was also getting prematurely deleted by target=clean in ...pde-build/plugins/com.ibm.etools.tui.ui/build.xml. The fix was s/.../../g
Created attachment 35870 [details] proposed patch source.. will now always get processed as @dot regardless of whether or not the bundle classpath contains '.'. Generation of the clean targets also protects against destructive deletes which can be caused by variations on ".." ("a/.." etc).
Patch released in HEAD.
