sebb wrote:
> On 18/06/2008, Jörg Schaible <[EMAIL PROTECTED]> wrote:
[snip]
>> >
>> > IOException is:
>> > "This class is the general class of exceptions produced by failed or
>> > interrupted I/O operations. "
>> > One can see wrong passwords as an interrupted IO exception. For me
>> > t
On 18/06/2008, Jörg Schaible <[EMAIL PROTECTED]> wrote:
> Christian Grobmeier wrote:
>
> >>
> >>
> >> I agree with Torsten. There may occur other exceptions than plain
> >>> input/output errors.
> >>>
> >>
> >> For example ?
> >>
> >
> > hm, maybe those?
> > - putting the same file twic
Christian Grobmeier wrote:
>>
>>
>> I agree with Torsten. There may occur other exceptions than plain
>>> input/output errors.
>>>
>>
>> For example ?
>>
>
> hm, maybe those?
> - putting the same file twice under same name in an archive
> - putting different files twice under same name in an arc
>
>
> +1 that would not be the place to throw a NPE IMO
>>
>
> You are right sorry, thought it was a method parameter.
>
No worries :-) Glad you jumped in and give so much feedback! That is
motivating!
Torsten Curdt a écrit :
+1 that would not be the place to throw a NPE IMO
You are right sorry, thought it was a method parameter.
Emmanuel Bourg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [E
Btw, regading this code in ArchiveStreamFactory :
if (clazz == null) {
throw new ArchiveException("ArchiverFactory could not create
instance");
}
Shouldn't this throw a NullPointerException instead ?
I would like to be carefully with throwing NullPointerException. In
that
case we
>
> input/output errors.
>>
> I agree with Torsten. There may occur other exceptions than plain
>
> I looked at the code, indeed the exceptions in the refactored compress are
> always related to configuration issue, whereas in the current svn code
> errors are often created on IO issues (path not w
Christian Grobmeier a écrit :
I agree with Torsten. There may occur other exceptions than plain
input/output errors.
I looked at the code, indeed the exceptions in the refactored compress
are always related to configuration issue, whereas in the current svn
code errors are often created on I
>
>
> I agree with Torsten. There may occur other exceptions than plain
>> input/output errors.
>>
>
> For example ?
>
hm, maybe those?
- putting the same file twice under same name in an archive
- putting different files twice under same name in an archive
- try to set unix permissions in an spe
Christian Grobmeier a écrit :
I agree with Torsten. There may occur other exceptions than plain
input/output errors.
For example ?
We had a discussion at this list long time before. If you are interested,
you may want to search the mailinglists.
I'll get a look, I haven't review all the p
Torsten Curdt a écrit :
I don't realy see that being an argument :) ...theyhe did other very
weird design decisions, too. :)
Well, at least I'm not the only one to think that :)
It's also the most debatable topic, and it will delay the release. The
other stuff is ready for a release.
>
> >> OK, we've never been consistent with our notation and some
> >> committers liked HN You probably don't find any in the zip package.
> >
> > * @author Stefan Bodewig
>
> If anybody could remove that, I'd be grateful. That email address
> died many years ago (not exaggerating) and in additio
>
> 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
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
IOExcepti
On Wed, 18 Jun 2008, Emmanuel Bourg <[EMAIL PROTECTED]> wrote:
> Stefan Bodewig a écrit :
>
>> On Solaris a file with the extension .jar whose first ZIP extra
>> field has the ID 0xCAFE (and is otherwise empty) is considered
>> executable and automatically handed of to Java as a "shell".
>>
>> Th
Stefan Bodewig a écrit :
On Solaris a file with the extension .jar whose first ZIP extra field
has the ID 0xCAFE (and is otherwise empty) is considered executable
and automatically handed of to Java as a "shell".
The jar tool in Sun's JDK adds this extra field and so does Ant's jar
task.
Is i
On Wed, 18 Jun 2008, Torsten Curdt <[EMAIL PROTECTED]> wrote:
>> - Ant has a JarMarker class that extends ZipExtraField, is there an
>> equivalent ?
>
> Could you elaborate?
On Solaris a file with the extension .jar whose first ZIP extra field
has the ID 0xCAFE (and is otherwise empty) is consid
On Wed, 18 Jun 2008, Emmanuel Bourg <[EMAIL PROTECTED]> wrote:
> Stefan Bodewig a écrit :
>
>> OK, we've never been consistent with our notation and some
>> committers liked HN You probably don't find any in the zip package.
>
> * @author Stefan Bodewig
If anybody could remove that, I'd be gra
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. An issue during a compression or
archive operation is an IO exception to me. The TrueZIP developers made
the same assumpt
Stefan Bodewig a écrit :
OK, we've never been consistent with our notation and some committers
liked HN You probably don't find any in the zip package.
* @author Stefan Bodewig
* @version $Revision: 155439 $
*/
public class ZipEntry extends java.util.zip.ZipEntry
{
private static Metho
On Wed, 18 Jun 2008, Torsten Curdt <[EMAIL PROTECTED]> wrote:
>> - the exceptions could extend IOException
>
> Could - but why restrict it that way? (composition over inheritance)
>
>> - I'm not sure to understand the purpose of the jar classes, isn't
>> a jar just a renamed zip ?
>
> Essential
Hi
A higher level API to manipulate the archives would be nice, but I believe
> an initial release could be made with just the stream classes.
>
Hm ...indeed. But IMO the changeset stuff is where it actually gets
> interesting :)
>
changeset is great :-) however an initial release with the stre
- the exceptions could extend IOException
Could - but why restrict it that way? (composition over inheritance)
- I'm not sure to understand the purpose of the jar classes, isn't a
jar just a renamed zip ?
Essentially - yes. But the JDK also handles them differently because
of meta data an
Christian Grobmeier a écrit :
thanks for your comments below. They all make sense.
I committed the changes to get a hand on the code, but I won't go
farther since your code base is much more advanced.
However, Thorsten and I currently develop a new and (hopefully) better
implementation
th
>
> I'll give it a look. I wanted to see how the Ar classes from jdeb could fit
> into commons compress.
Cool!
Thorsten allready included some ArArchivers code, you may want to .take a
look into:
src\main\java\org\apache\commons\compress\archivers\ar
Christian Grobmeier a écrit :
I use cygwin and could check out with:
$ git clone http://projects.grobmeier.de/compress-redesign.gitcompress-redesign
I created a zip file for you:
http://projects.grobmeier.de/compress-redesign-draft1.zip
Thank you! I was about to clone it with Ubuntu on VMWare
Hi
> Git is problematic for Windows. I tried to clone the repository with
> msysgit but it failed with the following error :
>
>fatal: Couldn't find remote ref HEAD
>
I use cygwin and could check out with:
$ git clone http://projects.grobmeier.de/compress-redesign.gitcompress-redesign
I crea
Christian Grobmeier a écrit :
However, Thorsten and I currently develop a new and (hopefully) better
implementation
than that which is currently available. That implementation fixes some of
the issues you mentioned.
If you want to take a look at it, please check it out via GIT:
http://projects.g
Hi Emmanuel,
thanks for your comments below. They all make sense.
However, Thorsten and I currently develop a new and (hopefully) better
implementation
than that which is currently available. That implementation fixes some of
the issues you mentioned.
If you want to take a look at it, please chec
I looked a bit at commons compress, I'd like to make a couple suggestions:
- FileOutputStream and FileInputStream are used in several method
signatures, but a simple OutputStream or InputStream would do the job.
It's limiting the API to files only for no apparent reason.
- I believe it would
30 matches
Mail list logo
