In some communication with me regarding his bug report #205 Steve Zindel <[EMAIL PROTECTED]> described two problems he had with <jlink>.
Matthew and Patrick, could you please take a look into this? (1) merging of jar files produces a corrupt file if compress is true. Steve is not subscribed here, I forward part of one of his messages with his permission: SZ> And then I also found out that the merging of jar files somehow SZ> produces corrupted jar files. If I want to see the content of SZ> the jar file (jar tf <file>) I get a "java.util.zip.ZipException: SZ> invalid stored block lengths" exception. This only happens if I SZ> set the compress attribute on jlink to true. The file seems to be SZ> alright if I turn compress to false. Are these problems I SZ> experienced known bugs? (2) Entries in META-INF/ are silently ignored. His use case was that he's built an EJB jar file (where the deployment descriptor resides in META_INF/) and then merged this one with another jar holding static content. jlink.mergeZipJarContents ignores all entries that have the string META-INF somewhere in there filename. So the resulting jar file didn't have a deployment descriptor and jlink didn't even tell him so. Comments indicate that this is to avoid problems with MANIFEST files. Could we change the check to only ignore META-INF/*.SF (as the signature won't be valid for the merged file) and META-INF/MANIFEST.MF? Maybe even allow for MANIFEST.MF? Stefan
