If path for signing jar look like c:\aaa\..\bbb\my.jar and not destDir nor destFile are defined sign procedure finish with error: jzfile = 43261776, total = 5, name = c:\bbb\my.jar\com.borland.orbit_8.2.3.v20101012-1621.jar, i = 1, message = couldn't read LOC header at java.util.zip.ZipFile$3.nextElement(ZipFile.java:429) at java.util.zip.ZipFile$3.nextElement(ZipFile.java:415) at sun.security.tools.JarSigner.getManifestFile(JarSigner.java:1449) at sun.security.tools.JarSigner.signJar(JarSigner.java:836) at sun.security.tools.JarSigner.run(JarSigner.java:194) at sun.security.tools.JarSigner.main(JarSigner.java:75) It happened because in SignJar.signOneJar(File jarSource, File jarTarget) jarSource = c:\aaa\..\bbb\my.jar jarTarget = c:\bbb\my.jar It points on the same file but !jarSource.equals(targetFile) So code add "-signedjar" argument in command call but should not. SignJar.signOneJar:377 //DO NOT SET THE -signedjar OPTION if source==dest //unless you like fielding hotspot crash reports if (!jarSource.equals(targetFile)) { addValue(cmd, "-signedjar"); addValue(cmd, targetFile.getPath()); }
Kiril, are you using the task from an ant build file or via its Java API. When usied from the Ant API, the "jarSource" should have been "normalized" by Ant and shpuld not contain any relative path remainders anymore.
I'm sorry. I thought about it just after submitting this bug. It is used via Java API in Eclipse PDE build. I will submit bug in Eclipse bugzilla.
Opening a bug report with Eclipse is fine, but then again we are providing the task with a public API and so should be more defensive about the paths. I'll get this fixed inside of Ant (as well - if the Eclipse people could fix their side, it would benefit users of released versions of Ant).
svn revision 1026982