You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Mario Ivankovits <ma...@ops.co.at> on 2006/01/03 10:51:33 UTC
[compress] what to do with?
Hi!
What to do with [compress]?
There is no development on the compress package, but VFS depends on it.
As you know, this is a show stopper for VFS to release.
The question now is if we should promote compress to proper and cut a
release or if I should import the required classes into the VFS codebase.
The latter might mean that compress will get dormant at all.
Personally I would like to keep compress as I hope sometimes in the
future we well see new compression algos too.
Might It be an option to move compress to [codec]? With some good will
;-) we can argue that it fits not that bad.
Ciao,
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [compress] what to do with?
Posted by James Ring <sj...@jdns.org>.
Hi all,
On Wednesday 04 January 2006 06:52, Brett Porter wrote:
> Ok, is there anyone else interested?
>
> I don't have any coding time available right now, but here's some things
> we can do:
> - create patches for these issues: http://tinyurl.com/bz3r8
It looks like there are already fixes for the four non-enhancement bugs at
this URL. Doesn't look like anybody's reviewed or committed them though.
I'm interested in seeing this component get a release. I think it could be
quite useful.
Regards,
James
--
James Ring
Re: [compress] what to do with?
Posted by "C. Grobmeier" <gr...@possessed.de>.
> Is there anything in particular you are interested in Chris?
I would like to add stuff to the zip-implementation, for example
deleting files from a zipfile. I would like to see this component
released and so i am also interested to discuss the api or to check
the Ant implementation Stefan mentioned.
I have time to do work end of next week.
Chris.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [compress] what to do with?
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 04 Jan 2006, Brett Porter <br...@apache.org> wrote:
> Ok, is there anyone else interested?
I might be, but know I won't find time.
The code originated from Ant via Excalibur IIRC and has evolved inside
of Ant a bit after it had been forked - you may want to check the
bugfixes and new features we've added over the past two or three years
there.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [compress] what to do with?
Posted by Brett Porter <br...@apache.org>.
Ok, is there anyone else interested?
I don't have any coding time available right now, but here's some things
we can do:
- create patches for these issues: http://tinyurl.com/bz3r8
- do a general review of the code to make sure it is javadoc'd/complete
- merge plexus-archiver (this is what I hope to replace):
http://svn.plexus.codehaus.org/trunk/plexus-components/plexus-archiver/,
which is derived from the same code.
- discuss the API that is thre now, and whether it is appropriate.
Is there anything in particular you are interested in Chris?
- Brett
C. Grobmeier wrote:
> Hi,
>
> I am interested in help with compress. I already read the code
> and checked out the zip-spec, but couldn't code something till now.
> Imaging an simple standalone compression helper makes me feel good.
>
> Chris
>
>
> Brett Porter wrote:
>> I intend to resuscitate compress, but I wouldn't want to have to
>> maintain the existing API (though not far off).
>>
>> Might be best to svn cp them into your own tree.
>>
>> - Brett
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [compress] what to do with?
Posted by "C. Grobmeier" <gr...@possessed.de>.
Hi,
I am interested in help with compress. I already read the code
and checked out the zip-spec, but couldn't code something till now.
Imaging an simple standalone compression helper makes me feel good.
Chris
Brett Porter wrote:
> I intend to resuscitate compress, but I wouldn't want to have to
> maintain the existing API (though not far off).
>
> Might be best to svn cp them into your own tree.
>
> - Brett
>
> Mario Ivankovits wrote:
>> Hi!
>>
>> What to do with [compress]?
>>
>> There is no development on the compress package, but VFS depends on it.
>> As you know, this is a show stopper for VFS to release.
>>
>> The question now is if we should promote compress to proper and cut a
>> release or if I should import the required classes into the VFS codebase.
>> The latter might mean that compress will get dormant at all.
>>
>> Personally I would like to keep compress as I hope sometimes in the
>> future we well see new compression algos too.
>> Might It be an option to move compress to [codec]? With some good will
>> ;-) we can argue that it fits not that bad.
>>
>>
>> Ciao,
>> Mario
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [compress] what to do with?
Posted by Brett Porter <br...@apache.org>.
I intend to resuscitate compress, but I wouldn't want to have to
maintain the existing API (though not far off).
Might be best to svn cp them into your own tree.
- Brett
Mario Ivankovits wrote:
> Hi!
>
> What to do with [compress]?
>
> There is no development on the compress package, but VFS depends on it.
> As you know, this is a show stopper for VFS to release.
>
> The question now is if we should promote compress to proper and cut a
> release or if I should import the required classes into the VFS codebase.
> The latter might mean that compress will get dormant at all.
>
> Personally I would like to keep compress as I hope sometimes in the
> future we well see new compression algos too.
> Might It be an option to move compress to [codec]? With some good will
> ;-) we can argue that it fits not that bad.
>
>
> Ciao,
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [compress] what to do with?
Posted by Henri Yandell <fl...@gmail.com>.
On 1/3/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
>
> What to do with [compress]?
>
> There is no development on the compress package, but VFS depends on it.
> As you know, this is a show stopper for VFS to release.
Yup.
> The question now is if we should promote compress to proper and cut a
> release or if I should import the required classes into the VFS codebase.
> The latter might mean that compress will get dormant at all.
How much of compress does VFS use?
ie) you could look to release a compress that just includes the bzip2
bit if that's all you use etc. Probably drive somebody to fix the
other parts for a later release.
> Personally I would like to keep compress as I hope sometimes in the
> future we well see new compression algos too.
> Might It be an option to move compress to [codec]? With some good will
> ;-) we can argue that it fits not that bad.
Nah, it's a good component in concept, just needs work. Not as if
there's a huge codec team jumping up and down looking for new stuff to
do.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org