-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Henri Yandell wrote:
> If you could fill out the software grant:
>
> http://www.apache.org/licenses/#grants
>
> and either fax or postal-mail it (see instructions in first paragraph
> of "http://www.apache.org/licenses/icla.txt";).
[x] done via fax
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>> So my comments:
>>
>> o Don't like that compressor does both compression and decompression.
>
> I'm ambivalent on this one.
>
If we would do so, we have 4 different interfaces. But i like the look.
>> o Always use File not String
>
> +1. Only u
On 5/2/06, Torsten Curdt <[EMAIL PROTECTED]> wrote:
Sorry, joining the party so late ...but this thread let me to actually
have a look ;)
So my comments:
o Don't like that compressor does both compression and decompression.
I'm ambivalent on this one.
o Always use File not String
+1. Only
Sorry, joining the party so late ...but this thread let me to actually
have a look ;)
So my comments:
o Don't like that compressor does both compression and decompression.
o Always use File not String
o Please parameter overloading ...this method naming scheme makes
the API really ugly
But to
On 5/1/06, Sandy McArthur <[EMAIL PROTECTED]> wrote:
On 4/30/06, will pugh <[EMAIL PROTECTED]> wrote:
> 1) You often change method names based on the parameter types, e.g.
> Archiver.addFile + Archiver.addFileName, setUnpackDestinationName +
> setUnpackDestinationFile, etc. It seems more conven
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> My fault for only just joining in etc, but why have the underlying
> Tar/Zip classes become package scoped? Does the bridging API replace
> all need to dig into the lower-level APIs?
>
I was not thinking enough about this. In my fault i was thinkin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sandy McArthur wrote:
> On 4/30/06, C. Grobmeier <[EMAIL PROTECTED]> wrote:
>> here is a new draft for the compress interface:
>>
>> * http://grobmeier.de/commons-compress-draft-5.zip
>
> Same as before, suggestions as a stream of consciousness, take
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Henri Yandell wrote:
> If you could fill out the software grant:
>
> http://www.apache.org/licenses/#grants
>
> and either fax or postal-mail it (see instructions in first paragraph
> of "http://www.apache.org/licenses/icla.txt";).
>
I will fill ou
I'm not sure if there is some requirement I'm missing, but
1) It still seems strange to me that we have an interface that does two
things: pack an archive + unpack an archive, yet it has 16 methods on it.
Of these, 9 seem to be some variation of property getters/setters.
As far as I can t
I may be missing some requirements here, but it seems like in light of
the JavaBean bits we were talking about, that it makes sense to restrict
the properties on the actual interface, and have them correspond
directly to JavaBean properties. In addition, I would propose getting
rid of some pro
On 5/1/06, will pugh <[EMAIL PROTECTED]> wrote:
Sandy McArthur wrote:
> On 4/30/06, will pugh <[EMAIL PROTECTED]> wrote:
>
>> 1) You often change method names based on the parameter types, e.g.
>> Archiver.addFile + Archiver.addFileName, setUnpackDestinationName +
>> setUnpackDestinationFile,
On 4/30/06, C. Grobmeier <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello all,
here is a new draft for the compress interface:
* http://grobmeier.de/commons-compress-draft-5.zip
My fault for only just joining in etc, but why have the underlying
Tar/Zip classes b
Sandy McArthur wrote:
On 4/30/06, will pugh <[EMAIL PROTECTED]> wrote:
1) You often change method names based on the parameter types, e.g.
Archiver.addFile + Archiver.addFileName, setUnpackDestinationName +
setUnpackDestinationFile, etc. It seems more conventional and less
chaotic to give
On 4/30/06, will pugh <[EMAIL PROTECTED]> wrote:
1) You often change method names based on the parameter types, e.g.
Archiver.addFile + Archiver.addFileName, setUnpackDestinationName +
setUnpackDestinationFile, etc. It seems more conventional and less
chaotic to give all the methods the same n
It occured to me later on, that I think this interface would be better
if it were focused on describing an Archive, rather than trying to
describe two processes (ie describing the noun rather than all the
verbs). The fall out from this, is that you don't have a member for an
unpack directory,
Overall, I like the interfaces, but I've got a few issues:
0) Update is mentioned in the Javadoc at the beginning of Archiver, but
is not implemented.
1) You often change method names based on the parameter types, e.g.
Archiver.addFile + Archiver.addFileName, setUnpackDestinationName +
set
On 4/30/06, C. Grobmeier <[EMAIL PROTECTED]> wrote:
here is a new draft for the compress interface:
* http://grobmeier.de/commons-compress-draft-5.zip
Same as before, suggestions as a stream of consciousness, take the
ones you like:
package org.apache.commons.compress:
In Archiver:
Why do pa
Sounds good, I'll look at the code tonight (hopefully) and comment; in
the meantime, let's go ahead and get a software grant moving for the
code.
If you could fill out the software grant:
http://www.apache.org/licenses/#grants
and either fax or postal-mail it (see instructions in first paragrap
18 matches
Mail list logo
