On Jun 18, 2008, at 10:32, Emmanuel Bourg wrote:
Torsten Curdt a écrit :
- the exceptions could extend IOException
Could - but why restrict it that way? (composition over inheritance)
I don't see this as a restriction.
Well, it means all ArchiveException necessarily need to be
IOExceptions. That's restricts their type.
I don't see the benefit.
An issue during a compression or archive operation is an IO
exception to me. The TrueZIP developers made the same assumption:
https://truezip.dev.java.net/nonav/javadoc-6/de/schlichtherle/io/ArchiveException.html
I don't realy see that being an argument :) ...they^^^^he did other
very weird design decisions, too. :)
- IOUtils.copy(in, out) could call copy(in, out, size)
Where is that?
In the org.apache.commons.compress.utils.IOUtils class from Chris
archive.
Ah
- the header in ArArchive*Stream could be factorized (ArConstants?
along with the sizes of the entry fields)
Hm ...IMO only useful if used somewhere else. Otherwise it's just
work. Or where do you see the benefit?
Just to have a cleaner code. PMD or Checkstyle will complain about
"magic numbers" otherwise.
Cleaner code is debatable :) ...but if someone wants to do it. *shrug*
- Ant has a JarMarker class that extends ZipExtraField, is there
an equivalent ?
Could you elaborate?
I don't know what it is, but it seems the Ant source is more recent
than the code in compress, it might be good to resync the code with
Ant.
+1
Hm ...indeed. But IMO the changeset stuff is where it actually gets
interesting :)
It's also the most debatable topic, and it will delay the release.
The other stuff is ready for a release.
In what sense debatable?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
