Major Description
Currently clients of ParallelScatterZipCreator could provide ZipArchiveEntry and InputStreamSupplier through ParallelScatterZipCreator#addArchiveEntry. From those two a ZipArchiveEntryRequest is created. Providing InputStreamSupplier solves the problem with opening too many files - streams are opened just-in-time - when an entry is compressed, not when it's submitted.
But there are use cases when the stream may contain information about the ZipArchiveEntry. In those cases creating ZipArchiveEntry before the InputStream is opened won't work. If there is an option to supply both ZipArchiveEntry and InputStreamSupplier (ZipArchiveEntryRequest), this will solve the issue.
There is a bug in Plexus Archiver (https://github.com/codehaus-plexus/plexus-archiver/issues/53) that is example for such use case. Plexus Archiver have option that allows entries that are already zip files to be stored instead of compressed (AbstractZipArchiver.recompressAddedZips). To detect if given entry is zip archive, AbstractZipArchiver should read the first several bytes of the stream. So creating ZipArchiveEntry before the stream is opened is not useful - the compress mode is not known. Opening the stream when the ZipArchiveEntry is created won't work either. Because you can add entries to ParallelScatterZipCreator a lot faster than you could compress them you could open too many files very fast. And I don't think opening and closing the stream is an option as such operations could be relatively expensive in the general case. But if it could supply both the ZipArchiveEntry and the InputStream just-in-time (by passing ZipArchiveEntryRequestSupplier to ParallelScatterZipCreator) then the problem is solved.
What do you think? Does the addition of ParallelScatterZipCreator#addArchiveEntry(ZipArchiveEntryRequestSupplier) makes sense?
Attachments
Issue Links
- links to
