You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Christian Grobmeier <gr...@gmail.com> on 2009/03/19 07:56:09 UTC

[compress] Open Issues Discussion

Hi,
diving into the open issues, I would like prio them.

* SANDBOX-282 TAR formaT unspecified
https://issues.apache.org/jira/browse/SANDBOX-282
I would do this in version 1.1. Its an important thing, but will need
its time, at least, if I work on this :-)

* SANDBOX-286 BZip2CompressorInputStream doesn't work if wrapped into
InputStreamReader
https://issues.apache.org/jira/browse/SANDBOX-286
As far as I understand the discussion, there is no real solution for
this. Following the discussion on the issue it looks like implementing
available is not a nice thing to do since other implementations could
fail with receiving a wrong byte length. Jukka allready pointed out
the way to go, so is this bug a "won't fix"?

* SANDBOX-293 Make ZiparchiveInputStream support as much of the zip
package as possible
https://issues.apache.org/jira/browse/SANDBOX-293
Looks like big work here. Even if it looks necessary, I would enjoy if
we do that in 1.1. It feels like a new feature instead of a bug to me.

* SANDBOX-280 unable to extract a TAR file that contains an entry
which is 10 GB in size
https://issues.apache.org/jira/browse/SANDBOX-280
I think this one is related to the solution of SANDBOX-282 and would
like to see it in 1.1 too

* SANDBOX-176 Enable creation of tool-readable ZIP archives with file
names containing non-ASCII characters
https://issues.apache.org/jira/browse/SANDBOX-176
I admit I didn't read everything here today :-) Is this solved? The
discussion has been ended with a commit from Stefan

* SANDBOX-296 Ar doesn't delete correct
We should fix that before the first release. Only other option imho is
to leave it out completly

* SANDBOX-300 Threading Requirements
We should fix

* SANDBOX-124 [compress] bzip2 - implement flush()
https://issues.apache.org/jira/browse/SANDBOX-124
Stefan said (see issue comments), this is fixed - if so, can we close that one?

* SANDBOX-295 JarArchiveEntry does not populate manifestAttributes or
certificates
https://issues.apache.org/jira/browse/SANDBOX-295
This is an enhancement. If time, we can fix, but I don't think this is
a must have for 1.0.

If you agree with me, I reorder the Roadmap page on the wiki and start
fixing with that prios.

Cheers
Christian

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


Re: [compress] Open Issues Discussion

Posted by Christian Grobmeier <gr...@gmail.com>.
Thanks Stefan and Sebb,

I reorganized the wiki page on that basis.
http://wiki.apache.org/commons/CompressRoadmap

Christian


On Fri, Mar 20, 2009 at 6:19 AM, Stefan Bodewig <bo...@apache.org> wrote:
> On 2009-03-19, Christian Grobmeier <gr...@gmail.com> wrote:
>
>> * SANDBOX-293 Make ZiparchiveInputStream support as much of the zip
>> package as possible
>> https://issues.apache.org/jira/browse/SANDBOX-293
>> Looks like big work here. Even if it looks necessary, I would enjoy if
>> we do that in 1.1. It feels like a new feature instead of a bug to me.
>
> I was hoping to find time to do it - it shouldn't be too hard to do,
> but still takes time.  Not sure when I'll get around to it, so
> postponing it may be good.
>
>> * SANDBOX-176 Enable creation of tool-readable ZIP archives with file
>> names containing non-ASCII characters
>> https://issues.apache.org/jira/browse/SANDBOX-176
>> I admit I didn't read everything here today :-) Is this solved? The
>> discussion has been ended with a commit from Stefan
>
> Pending proper documentation it is, but only if you use ZipFile and
> not ZipArchiveInputStream (and thus the Achive*Factory) - the missing
> part is SANDBOX-293.
>
> Agreed with the rest
>
>       Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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


Re: [compress] Open Issues Discussion

Posted by Stefan Bodewig <bo...@apache.org>.
On 2009-03-19, Christian Grobmeier <gr...@gmail.com> wrote:

> * SANDBOX-293 Make ZiparchiveInputStream support as much of the zip
> package as possible
> https://issues.apache.org/jira/browse/SANDBOX-293
> Looks like big work here. Even if it looks necessary, I would enjoy if
> we do that in 1.1. It feels like a new feature instead of a bug to me.

I was hoping to find time to do it - it shouldn't be too hard to do,
but still takes time.  Not sure when I'll get around to it, so
postponing it may be good.

> * SANDBOX-176 Enable creation of tool-readable ZIP archives with file
> names containing non-ASCII characters
> https://issues.apache.org/jira/browse/SANDBOX-176
> I admit I didn't read everything here today :-) Is this solved? The
> discussion has been ended with a commit from Stefan

Pending proper documentation it is, but only if you use ZipFile and
not ZipArchiveInputStream (and thus the Achive*Factory) - the missing
part is SANDBOX-293.

Agreed with the rest

       Stefan

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


Re: [compress] Open Issues Discussion

Posted by sebb <se...@gmail.com>.
On 19/03/2009, Christian Grobmeier <gr...@gmail.com> wrote:
> Hi,
>  diving into the open issues, I would like prio them.
>
>  * SANDBOX-282 TAR formaT unspecified
>  https://issues.apache.org/jira/browse/SANDBOX-282
>  I would do this in version 1.1. Its an important thing, but will need
>  its time, at least, if I work on this :-)
>
>  * SANDBOX-286 BZip2CompressorInputStream doesn't work if wrapped into
>  InputStreamReader
>  https://issues.apache.org/jira/browse/SANDBOX-286
>  As far as I understand the discussion, there is no real solution for
>  this. Following the discussion on the issue it looks like implementing
>  available is not a nice thing to do since other implementations could
>  fail with receiving a wrong byte length. Jukka allready pointed out
>  the way to go, so is this bug a "won't fix"?
>
>  * SANDBOX-293 Make ZiparchiveInputStream support as much of the zip
>  package as possible
>  https://issues.apache.org/jira/browse/SANDBOX-293
>  Looks like big work here. Even if it looks necessary, I would enjoy if
>  we do that in 1.1. It feels like a new feature instead of a bug to me.
>
>  * SANDBOX-280 unable to extract a TAR file that contains an entry
>  which is 10 GB in size
>  https://issues.apache.org/jira/browse/SANDBOX-280
>  I think this one is related to the solution of SANDBOX-282 and would
>  like to see it in 1.1 too
>
>  * SANDBOX-176 Enable creation of tool-readable ZIP archives with file
>  names containing non-ASCII characters
>  https://issues.apache.org/jira/browse/SANDBOX-176
>  I admit I didn't read everything here today :-) Is this solved? The
>  discussion has been ended with a commit from Stefan
>
>  * SANDBOX-296 Ar doesn't delete correct
>  We should fix that before the first release. Only other option imho is
>  to leave it out completly
>
>  * SANDBOX-300 Threading Requirements
>  We should fix
>
>  * SANDBOX-124 [compress] bzip2 - implement flush()
>  https://issues.apache.org/jira/browse/SANDBOX-124
>  Stefan said (see issue comments), this is fixed - if so, can we close that one?
>
>  * SANDBOX-295 JarArchiveEntry does not populate manifestAttributes or
>  certificates
>  https://issues.apache.org/jira/browse/SANDBOX-295
>  This is an enhancement. If time, we can fix, but I don't think this is
>  a must have for 1.0.
>
>  If you agree with me, I reorder the Roadmap page on the wiki and start
>  fixing with that prios.

Seems all good to me.

>  Cheers
>  Christian
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

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