Bugzilla – Full Text Bug Listing
| Summary: | case of letters (upper/lower) in Bundle-ClassPath in MANIFEST.MF affects 'eclipse.buildScript' Ant task | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | John Cortell <john.cortell> | ||||||||
| Component: | Build | Assignee: | pde-build-inbox <pde-build-inbox> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | aniefer | ||||||||
| Version: | 3.6 | ||||||||||
| Target Milestone: | 3.7 M5 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows XP | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
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. |
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.