On 15 December 2014 at 17:47, Kristian Rosenvold <krosenv...@apache.org> wrote: > 2014-12-15 17:39 GMT+01:00 Stefan Bodewig <bode...@apache.org>: >> On 2014-12-15, Kristian Rosenvold wrote: >> >>> There is also the issue of determining if the MANIFEST.MF file really >>> needs to be the first file in the jar, which puts an interesting >>> constraint on the parallelism. I have been unable to understand if the >>> jar spec actually requires this or if it's just stuff from the old >>> days. >> >> AFAIR the jar spec does not require it, but many tools do - maybe even >> java.util.jar, but I'm not sure. >> >> When distinguishing a jar from a "normal" zip most tools require the >> "jar marker" to be the first zip extra field of the first entry - and >> IIRC some tools we've come across required this entry to be the META-INF >> directory. > > Some of our code in maven goes through some serious hoops to preserve > this, so I've been prepared for this although I really don't like it > :) In the context of parallel streams it just means there'll be a > "root" stream which will be the start of the archive. It might even > end up being more efficient than our current algorithm, which scans > the input filenames twice to determine if there is manifest-worthy > content. > > My git repo now has a first *crude* working version of the code with a > passing testcase, which means I can merge multiple streams. The > hacking continues :)
Just wondering if this feature might help with another recent request, which was to allow entries to be copied from one archive to another without having to unpack/repack them? Seems to me that the parallel streams are presumably already compressed, so the "only" part that is missing is extraction of the compressed data from the input zip. Of course, that may be the hardest part. Just a thought in case it affects the merge API. > K > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
