commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Pugh <willp...@sourcelabs.com>
Subject Re: [compress] Re: VFS & jar files
Date Wed, 03 Jan 2007 18:54:50 GMT
Sorry, it took me a while.  Work + Holidays made everything pretty crazy.

I've created a new Jira issue 
(https://issues.apache.org/jira/browse/SANDBOX-183)  and attached my 
code there.

It is right now standalone, and not integrated with compress.  I've been 
thinking a little about how to integrate the two together, and there are 
a few issues:

    1)  I use NIO for my IO.  This is pretty useful for me, because when 
I modify the zip files, I try to do as little extra work as possible.  
As a result, I try to not have to re-compress unmodified blocks, but I 
sometimes need to slide them in the file.  I found using ByteBuffers 
here was a bit nicer.   I thought a JDK 1.4 dependency here was not 
crazy, especially since Compress is still in the sandbox.   I think I 
can get rid of this dependency if needed.

    2)  I did not use org.apache.commons.compress.zip.ZipOutputStream.  
This was because it seemed tricky to have a stream that could delete and 
modify entries.  Brainstorming a bit, I was thinking I could potentially 
merge my code with ZipOutputStream by being able to give it the partial 
state of the zip file it is adding to.  That way, all entries written to 
the zip file would be taken care of via the ZipOutputStream, and then 
some kind of ModifiableArchiver class would be able to take care of the 
logic for dealing with deletes and modifications.  (I treat 
modifications as a delete then add).


I had a ModifiableZipFile class that took care of keeping track of all 
the additions and modifications on a ZipFile.

    --Will

C. Grobmeier wrote:
> Cheers,
>
> sorry for my delay with compress i was quite busy last months.
>
>> 1) you finish the compress api change so that we can release it (and add
>> your code for sure) :-)
>
> There is not much to do there- look at this:
> http://wiki.apache.org/jakarta-commons/Compress
>
> I would like to simplify the api a bit (delete methods) but thats it. 
> The code could go into compress quite quick if a comitter supports it 
> (i am no one).
>
> Will, could you post a link to your proposal code at the dev list 
> again? I could integrate your code into the compress api. I have a bit 
> time at the moment, so it would be great to take a closer look at it 
> asap.
>
>> 2) you add your zip enhancements to VFS - we added the old compress code
>> so that we are able to get rid of any snapshot dependency so we can have
>> a VFS release. Yes, yes I know, still no time to cut the release ....
>>
>> In either way, please ensure you use the org.apache.compress/vfs
>> namespace, add the AFS license header and file a CLA (in case you didn't
>> in the past already)
>>
>>
>> For sure, I prefer the way 1.
>
> Me 2.
> Regards,
> Chris
>
>>
>> Ciao,
>> Mario
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message