I just landed two commits for COMMONS-295 and COMMONS-296, which is
the groundwork for proper parallel support. The icing on the cake (the
high-level api with "nThreads" configuration and single point of
entry) is still work-in-progress and can be seen at
https://github.com/krosenvold/commons-compr
+1 for moving to git btw :)
Kristian
2014-12-15 11:38 GMT+01:00 Emmanuel Bourg :
> Le 15/12/2014 11:36, Stefan Bodewig a écrit :
>
>> [as an aside, maybe we should think about moving Compress to git]
>
> +1
>
> Emmanuel
>
>
> -
>
Le 16/12/2014 10:35, Stefan Bodewig a écrit :
> Coming to think of it again, cpio and tar don't have any concept of a
> central directory so a scatter/gather approach may even work OOTB. ar
> has this "long file name" thing that would need to be taken care of and
> 7z is pretty similar to zip, ju
On 2014-12-16, Kristian Rosenvold wrote:
> At least for maven's code, introducing the concept of a "root" stream
> that will be the start of the physical zip stream can simplify things
> quite a lot.
Yes, I can see the same for "my" compress antlib (Ant tasks based on
Commons Compress) as well.
Amazing digging; thanks a lot. At least for maven's code, introducing
the concept of a "root" stream that will be the start of the physical
zip stream can simplify things quite a lot.
Kristian
2014-12-16 6:48 GMT+01:00 Stefan Bodewig :
> On 2014-12-15, Kristian Rosenvold wrote:
>
>> There is als
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've found this for Ant which caused us to implement that logic (in 2001):
https://
On 15 December 2014 at 17:47, Kristian Rosenvold wrote:
> 2014-12-15 17:39 GMT+01:00 Stefan Bodewig :
>> 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
>>> co
2014-12-15 17:39 GMT+01:00 Stefan Bodewig :
> 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
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
As far as I understand there will be no thread pools coming into
commons-compress, this has to be done by the caller. The caller will
basically in some shape or another keep at ThreadLocal<
ZipArchiveOutputStream> that will receive entries for each thread.
When everyone is finished they will be mer
Sounds cool. Do you plan on allowing an executor service to be passed in to
some APIs?
Gary
Original message From: Kristian Rosenvold
Date:12/15/2014 02:49 (GMT-05:00)
To: Commons Developers List Cc:
Subject: [compress] Changes to allow multithreaded creation of zip
f
Le 15/12/2014 11:36, Stefan Bodewig a écrit :
> [as an aside, maybe we should think about moving Compress to git]
+1
Emmanuel
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h.
On 2014-12-15, Kristian Rosenvold wrote:
> I just thought I'd let you know I'm working on changes to allow
> multiple threads to output to different ZipArchiveOutputStream
> instances (backed by commons-io DeferredFileOutputStream or similar)
> and then stitch the results back together as a singl
Hello Kristian,
2014-12-15 8:49 GMT+01:00 Kristian Rosenvold :
>
> I just thought I'd let you know I'm working on changes to allow
> multiple threads to output to different ZipArchiveOutputStream
> instances (backed by commons-io DeferredFileOutputStream or similar)
> and then stitch the results
14 matches
Mail list logo
