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
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
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
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
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 single Zip file. I'm
currently just researching the sco
15 matches
Mail list logo
