nedtwigg
commented
6 years ago Hmm... It's always been a little unclear to me whether model/ belonged in the zip file, or if it would just be implicitly created because it's a prerequisite for model/fileA.xyz. The ZipMisc model ignores parent directories entirely - it creates them if needed when extracting, and doesn't worry about them when encoding.
The nice thing about ZipMisc, as it is, is that it tries to modify the zip file as little as possible - it just copies entries over wholesale. To make the "names" work, we'll have to first read the whole file upfront to populate names.
It looks to me like model/ is being implicitly added to the zip file when we add model/fileA.xyz, which is what causes explicitly adding model/ to fail. Seems that ZipMisc's previous input has always been either this:
model/fileA.xyz
model/fileB.xyzor
model/
model/fileA.xyz
model/fileB.xyzand now, for whatever reason, for the first time it's seeing
model/fileA.xyz
model/fileB.xyz
model/I could be wrong in my diagnosis, but if I'm correct, it seems to me that the easiest fix might be this:
} else if (!toOmit.test(entry.getName())) {
// if it isn't being modified, just copy the file stream straight-up
try {
ZipEntry newEntry = new ZipEntry(entry);
newEntry.setCompressedSize(-1);
zipOutput.putNextEntry(newEntry);
copy(zipInput, zipOutput);
} catch (java.util.zip.ZipException e) {
if (e.getMessage().startsWith("duplicate entry")) {
// no worries, sometimes input zips have strange orders, see https://github.com/diffplug/goomph/issues/84
} else {
throw e;
}
}
hacki11
I have a module where ZipMisc has a problem saying a path would be duplicate.
there are some resources within my module like:
model/fileA.xyz model/fileB.xyz
During the BndManifestPlugin
ZipMisc.modify(jarTask.getArchivePath(), toModify, Predicates.alwaysFalse());it wants to add the files in the following order:model/fileA.xyz model/fileB.xyz model/
The last entry is the problem here.
My fix would be to check if the entry already exists in ZipMisc: