Community
Participate
Working Groups
I just spent the afternoon figuring out why a co-worker's feature wasn't building in a headless environment. To say the problem wasn't obvious is an understatement. It turned out to be that the PDE Ant task that generates build.xmls for a features/plugins is sensitive to the case of OSGI keywords: "Bundle-ClassPath", at a minimum. This inconsistency has great potential for sending someone on a long drive into the weeds. This issue was discovered with Ganymede and reproduced with Helios. Reproducibility Steps on Windows: 1. Launch Helios 2. Create a new workspace: {eclipse.home}\workspace_test 3. Unzip the attached archive to that directory. It contains three PDE projects. 4. Import the projects into the workspace via File > Import > General > Existing Projects into Workspace 5. Exit eclipse 6. Copy attached go.cmd.rename.me and genbuild.xml to {eclipse.home}. Rename the cmdfile 7. Open command window and run go.cmd All the projects should now have a build.xml 8. Open {eclipse.home}\workspace_test\com.acme.dependsonsomething\build.xml 9. Search for "/../com.acme.something". It will take you to a <pathelement> Note that "com.acme.something.jar" is being referenced. That's expected. 10. Open {eclipse.home}\workspace_test\com.acme.something\META-INF\MANIFEST.MF in a text editor 11. Change the 'P' in 'Bundle-ClassPath' to lowercase 12. Repeat steps 7-9 Note that 'com.acme.something.jar' is no longer referenced. The script now expects to find class files in bin and @dot folders instead of a jar. That is a major and unexpected change to the build behavior of that plugin.
Created attachment 178987 [details] Zip refrenced in repro steps
Created attachment 178988 [details] Windows cmd file referenced in repro steps
Created attachment 178989 [details] Ant script invoked by go.cmd
I forgot to mention that other aspects of PDE don't seem to care about the case of Bundle-ClassPath (and other OSGi keywords?). E.g., regardless of case, the PDE Manifest editor interprets the keyword correctly. This is why I consider the Ant task behavior a bug.
I talked to Tom and OSGi bundle headers are indeed case-insensitive so this is possibly a problem with how PDE/Build reads the manifest when building. I'll ask Andrew to comment when he returns from holidays.
(In reply to comment #5) > I talked to Tom and OSGi bundle headers are indeed case-insensitive so this is > possibly a problem with how PDE/Build reads the manifest when building. I'll > ask Andrew to comment when he returns from holidays. Just pinging to see if someone can take a look at this. The problem was a big time-waster for me and I think someone else will eventually experience the same if not addressed.
Made manifest header lookup non-case-sensitive.
