Hi,
I'm currently using JDK 1.8 build 113 on some projects as we had reports
of incompatibilities on the Gump list. It may be worth doing that for
other components as well.
Anyway, two tests fail, both for the same reason:
org.tukaani.xz.XZIOException: Stream finished or closed
at org.tukaa
Hi all,
I've been working on COMPRESS-183 which is a more general version of
COMPRESS-114 we fixed a while ago. It asks for support of non-ASCII
file names in tar archives by using an explicit encoding (COMPRESS-114
made things work for ISO-8859-1 and any other encoding that creates the
Hi all,
the redesigned compress-codebase fixes this issue:
https://issues.apache.org/jira/browse/SANDBOX-245
It can be closed. Can somebody please do this?
Thanks!
Chris
-
To unsubscribe, e-mail: dev-unsubscr
Hi,
https://issues.apache.org/jira/browse/SANDBOX-195
describes a problem, which occurs in the Ant-BZIP2-Classes and in in
our implementation (which is an old version of the ant stuff).
I created a patch which updates our codebase to the current codebase
of ant which should fix a few problems, in
Hi,
please apply the patch provided here:
https://issues.apache.org/jira/browse/SANDBOX-273
It updates old and evil stenching TAR compress code with fresh, soft
coated ant code.
This is a must have, cause the newer implementations are fixing many bugs which
make it impossible to use compress, if
> Please review esspecially the license stuff which we discussed
> recently before applying.
I have it applied here locally and are ready for a commit.
I did change a few things though. I've removed the attribution from
the class files as we don't do author tags either. I would think the
attribut
> I have it applied here locally and are ready for a commit.
Cool!
> I did change a few things though. I've removed the attribution from
> the class files as we don't do author tags either. I would think the
> attribution in the NOTICE file should be enough. Or we add something
> more along the l
>> Could we maybe ask the jrpm project whether upgrading the license to
>> ASL 2.0 would be an option? Would make things a little cleaner IMO.
>
> I just wrote the guys an email and begged for a License change.
Great news:
The jRPM project has updated it License to AS 2.0.
For example:
http://jr
Awesome. Did the changes and just committed.
cheers
--
Torsten
On Mon, Jan 12, 2009 at 05:46, Christian Grobmeier wrote:
>>> Could we maybe ask the jrpm project whether upgrading the license to
>>> ASL 2.0 would be an option? Would make things a little cleaner IMO.
>>
>> I just wrote the guys an
> Is there any interest in these patches?
Please - bring them on and file them in jira ! :)
> Or is the commons-compress
> project dead?
No, it's not ... it just got it's make-over and more people seem to be
interested in it :)
> I hope this list is the right place to
Torsten Curdt wrote:
>> Is there any interest in these patches?
>
> Please - bring them on and file them in jira ! :)
>
I put everything concerning the magic number issue into this jira issue:
https://issues.apache.org/jira/browse/SANDBOX-285
Is this sufficient?
I am still investigating the se
I fixed the second issue and reported it here:
https://issues.apache.org/jira/browse/SANDBOX-286
Again, is this sufficient?
Kind regards,
Ingo
Ingo Rockel schrieb:
> Torsten Curdt wrote:
>>> Is there any interest in these patches?
>> Please - bring them on and file them in jira ! :)
>>
> I put everything concerning the magic number issue into this jira issue:
>
> https://issues.apache.org/jira/browse/SANDBOX-285
>
> Is this sufficient?
>
> I am still investigating the second issue, reading from the stream
> directly works fine, but it fails if it is wrapped into a InputStreamRead
On 2009-02-11, Ingo Rockel wrote:
> I fixed the second issue and reported it here:
> https://issues.apache.org/jira/browse/SANDBOX-286
> Again, is this sufficient?
absolutely, yes. Thanks.
A bit of history. The BZip classes used to be part of Ant (well, they
still are) and for reasons I can
Hi all,
I have improved the testcases for SANDBOX-183.
The patch is attached here:
https://issues.apache.org/jira/browse/SANDBOX-183
Here are the changes in the patch:
ChangeSet: removed System.out.println
AbstracTestCase: added a method which adds the src/test/resources
folder to the classpath.
On 2009-02-26, Christian Grobmeier wrote:
> I recently figured out that a compress created zip file doesn't
> necessary match the signature of
> ZipArchiveInputStream.matches(...)
This is because the method is wrong - will be "fixed" in a few
minutes, see below.
The
Thanks Stefan.
I allready thought that you can identify the problem within a short time.
> Note that the method (or better the input stream) is still broken in a
> more general sense since it will not detect self extracting ZIP files
> which do have a tiny native bootstrapper tacked to the front o
On 2009-02-26, Stefan Bodewig wrote:
> On 2009-02-26, Christian Grobmeier wrote:
>> I recently figured out that a compress created zip file doesn't
>> necessary match the signature of
>> ZipArchiveInputStream.matches(...)
> This is because the method is wro
On 2009-02-26, Christian Grobmeier wrote:
>> Note that the method (or better the input stream) is still broken in a
>> more general sense since it will not detect self extracting ZIP files
>> which do have a tiny native bootstrapper tacked to the front of the
>> archive. The ZipFile class can re
Hi,
I looked at the compress component in the sandbox and it's exactly
what we could use in Apache Tika, see [1].
What's the current status of the codebase? Any plans of graduation to
Commons proper and of doing a 1.0 release?
[1] https://issues.apache.org/jira/browse/TIKA-204
Hi all,
I have improved ChangeSet stuff a bit. It now supports most common
usecases as described in the testcase.
Of course I am still working on it, it lacks of java doc and I want to
do some findbugs with the next patch.
Please apply: https://issues.apache.org/jira/browse/SANDBOX-183
Patch:
ht
Hi,
when working on the Testcases i figured out that a deletion from an Ar
Archive is not as successful as it look at first glance.
For example: my bla.ar file contains test1.xml and test2.xml. I delete test2.xml
The "getNextEntry" Method just delivers test1.xml. Looks correct.
But checking the
Hi all,
since everybody seems to agree to promoting compress I collected several todos.
I would like to discuss what is necessary for release 1 and what is not.
* Of course administrative stuff: vote compress to proper etc. I don't
have a clue of that currently. Who of you feels responsibl
Hi all,
just made a quick fix for SANDBOX-284:
https://issues.apache.org/jira/browse/SANDBOX-284
I could not test it with a general working testcase, since this is a
platform problem and i have only OSX.
However, GUMP will not run on windows too, i guess. I think here is
some refactoring necessar
-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.ap
On 2009-03-19, Christian Grobmeier 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 n
roject for compress and move the SANDBOX issues
for component Compress over there.
Neither my JIRA karma nor knowledge are up to this task, we need
help.
* site updates
I'd like to defer that until I have figured out how to do it which
should happen sometime during ApacheCon next
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 wrote:
> On 2009-03-19, Christian Grobmeier wrote:
>
>> * SANDBOX-293 Make ZiparchiveInputStream support as much of the z
Hi folks,
'mvn site' fails due to a missing "checkstyle.xml" in pom.xml - is that
file missing or the pom wrong?
[INFO] Generating "Checkstyle" report.
[INFO]
[ERROR] BUILD ERROR
[INFO]
--
Hi,
how do I tell Continuum that compress has been promoted?
Thanks for any hint
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Hi,
The commons-compress NOTICE file currently contains the following entries:
Original BZip2 classes contributed by Keiron Liddle
, Aftex Software to the Apache Ant project
Original Tar classes from contributors of the Apache Ant project
Original Zip classes from contributors
On Thu, Mar 26, 2009 at 12:36 PM, sebb wrote:
> Would it be a silly idea to include both variants?
I'd clearly tend to avoid that. It would likely cause confusion.
On a related matter: Stefan, wouldn't it be possible for the others to
start using compress?
Jochen
--
I have
On 26/03/2009, Stefan Bodewig wrote:
> Hi folks,
>
> first of all I don't know enough about the bzip2 format to undestand
> the existing code, nor the one I'll be pointing at further down.
>
> The current code in compress is the one of Ant 1.7.1 and versions
>
and on the API?
I've not looked into it, but perhaps the implementation can be chosen
at construction-time via a parameter.
> On a related matter: Stefan, wouldn't it be possible for the others to
> start using compress?
>
> Jochen
>
>
>
> --
> I have always
On 2009-03-26, Jochen Wiedmann wrote:
> On a related matter: Stefan, wouldn't it be possible for the others to
> start using compress?
Not sure who "the others" may be.
As for Ant, I don't expect it to move away from its own classes.
Creating jars is a core requir
If the code has been tested by the folks at hadoop I trust it very
much. (They do extensive testing!) and would be all for replacing the
current code base. But IMO that's no blocker. In the end the algorithm
should be a black box for everyone using compress. So changing this in
a later re
>> On a related matter: Stefan, wouldn't it be possible for the others to
>> start using compress?
>
> Not sure who "the others" may be.
>
> As for Ant, I don't expect it to move away from its own classes.
> Creating jars is a core requirement fo
On 2009-03-26, Torsten Curdt wrote:
> If the code has been tested by the folks at hadoop I trust it very
> much. (They do extensive testing!) and would be all for replacing the
> current code base.
I just did it 8-)
svn revision 759143
Stefan
--
As you assumed,
getSize returns the size of file data for this entry (to be clear, no
header data).
I will write some javadoc for this class when I have my account ready.
Cheers,
Christian
On Fri, Mar 27, 2009 at 6:25 PM, sebb wrote:
> The interface ArchiveEntry does not have any Javadoc, and it
On 2009-03-29, sebb wrote:
> The existing ArchiveInputStream and ArchiveOutputStream abstract
> classes are quite minimal. Seems to me that there is quite a lot of
> common code that they could provide.
> For example, if the Stream was stored as a protected variable, then
> they could provide ge
>> We could also add some new methods with partial implementations, for example
>> putArchiveEntry(File)
>> extractFile(File basedir, Entry)
>
> If this is a common usecase, yes. The only real user of a simial API
> I know is Ant and here those methods wouldn't help since they don't
> provide a wa
Hi,
TarArchiveOutputStream, TarArchiveInputStream and TarBuffer contain a
variable named "debug". In the first class it does nothing.
If it is set in TarBuffer the flag produces some weird output on System.err.
Like this:
if (numBytes != blockSize) {
if (debug) {
On Thu, Apr 9, 2009 at 7:44 AM, Christian Grobmeier wrote:
> Hi,
>
> looking at:
> http://people.apache.org/builds/commons/nightly/commons-compress/
> shows me just some md5 hashes,
>
> but:
> http://people.apache.org/builds/commons/nightly/commons-vfs/
>
> has some
Thanks - i didn't looked at the date actually.
I will remove the compress link to that server.
Christian
On Thu, Apr 9, 2009 at 9:34 PM, Rahul Akolkar wrote:
> On Thu, Apr 9, 2009 at 7:44 AM, Christian Grobmeier
> wrote:
>> Hi,
>>
>> looking at:
>> http
Mental note that we need to remove that nightly directory.
On Thu, Apr 9, 2009 at 1:14 PM, Christian Grobmeier wrote:
> Thanks - i didn't looked at the date actually.
> I will remove the compress link to that server.
>
> Christian
>
>
> On Thu, Apr 9, 2009 at 9:34 PM, R
The Commons Compress team is pleased to announce the
commons-compress-1.0 release!
Commons Compress is a component that contains Ar, Cpio, Jar, Tar, Zip
and BZip2 packages
Source and binary distributions are available for download from the
Apache Commons download site:
http://commons.apache.org
> before ages VFS included the compress classes with own namespace,
> cause compress wasn't released and VFS had to go ahead. It was planned
> to replace those vfs.compress classes with a dependency to commons
> compress. If this is still the plan, I will create an issue for it
Bear's "traditional encryption".
This is one reason for COMPRESS-93, the other is to allow third parties
to hook in their implementations of encumbered methods (strong crypto,
DEFLATE64 or whatnot).
It's about time to seriously start thinking about a proper API for this
and
In the same vein it looks like the method 12 (bzip2) should be easy to
implement.
Emmanuel Bourg
Le 06/12/2013 20:26, Damjan Jovanovic a écrit :
> Hi
>
> I just committed a patch for decompressing ZIP entries using method 1
> ("unshrinking"), but it's only for ZipFile.
>
> If someone wants to
I suggest adding to the list a renaming of the constants in ZipMethod.
This enum defines the compression methods, but several constants have
the name of the decompression algorithm. There is also a mix between *ed
and *ing names.
UNSHRINKING -> SHRUNK
EXPANDING_LEVEL_n -> REDUCED_LEVEL_n
IMPLODING
Hi all,
ZipArchiveInputStream updates a CRC32 for each entry but the result is
never used. Any objection to remove it?
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail:
bably without the attribute
> view overhead) might come handy. OTOH it wouldn't be too complex to
> implement the same ideas ourselves.
>
If all we need is already present in Java 7, then we shouldn't reinvent the
wheel.
>
> Compress 1.x is at Java5, personally I don'
urselves.
> >
>
> If all we need is already present in Java 7, then we shouldn't reinvent the
> wheel.
>
+1
>
>
> >
> > Compress 1.x is at Java5, personally I don't think Java6 would give us
> > any benefits. I don't know about the other improvements in N
Le 30/12/2013 11:17, Stefan Bodewig a écrit :
> Is this too ambitious? Should we poll the user list?
I believe Commons Compress is a core dependency of the Maven ecosystem.
I don't know what is the minimum version of Java expected there, but we
should probably try to play nice w
On 2014-01-01, Emmanuel Bourg wrote:
> Le 30/12/2013 11:17, Stefan Bodewig a écrit :
>> Is this too ambitious? Should we poll the user list?
> I believe Commons Compress is a core dependency of the Maven ecosystem.
> I don't know what is the minimum version of Java ex
bably without the attribute
> view overhead) might come handy. OTOH it wouldn't be too complex to
> implement the same ideas ourselves.
>
> Compress 1.x is at Java5, personally I don't think Java6 would give us
> any benefits. I don't know about the other impro
Le 01/01/2014 23:09, Stefan Bodewig a écrit :
> AFAIK maven uses some Plexus component which is yet another fork of the
> codebase originating from Ant - must have been created at about the same
> time as Compress.
The forked code has been replaced in plexus-archiver 2.4 with a
depe
On 2014-01-02, Emmanuel Bourg wrote:
> Le 01/01/2014 23:09, Stefan Bodewig a écrit :
>> AFAIK maven uses some Plexus component which is yet another fork of the
>> codebase originating from Ant - must have been created at about the same
>> time as Compress.
> The forked c
On 2013-12-30, Stefan Bodewig wrote:
> Compress 1.x is at Java5, personally I don't think Java6 would give us
> any benefits. I don't know about the other improvements in NIO2 but the
> java.nio.file package looks useful for compress.
In the meantime it has been pointed out
On Fri, Jan 24, 2014 at 11:06 AM, Stefan Bodewig wrote:
> On 2013-12-30, Stefan Bodewig wrote:
>
> > Compress 1.x is at Java5, personally I don't think Java6 would give us
> > any benefits. I don't know about the other improvements in NIO2 but the
> > java
On 24 January 2014 16:57, Gary Gregory wrote:
> On Fri, Jan 24, 2014 at 11:06 AM, Stefan Bodewig wrote:
>
>> On 2013-12-30, Stefan Bodewig wrote:
>>
>> > Compress 1.x is at Java5, personally I don't think Java6 would give us
>> > any benefits. I don&#x
On Fri, Jan 24, 2014 at 6:06 PM, Stefan Bodewig wrote:
> On 2013-12-30, Stefan Bodewig wrote:
>
>> Compress 1.x is at Java5, personally I don't think Java6 would give us
>> any benefits. I don't know about the other improvements in NIO2 but the
>> java.nio.file
2014/1/25 Damjan Jovanovic
> On Fri, Jan 24, 2014 at 6:06 PM, Stefan Bodewig
> wrote:
> > On 2013-12-30, Stefan Bodewig wrote:
> >
> >> Compress 1.x is at Java5, personally I don't think Java6 would give us
> >> any benefits. I don't kno
>> > On 2013-12-30, Stefan Bodewig wrote:
>> >
>> >> Compress 1.x is at Java5, personally I don't think Java6 would give us
>> >> any benefits. I don't know about the other improvements in NIO2 but the
>> >> java.nio.file package looks
On 2014-01-25, Damjan Jovanovic wrote:
> On Fri, Jan 24, 2014 at 6:06 PM, Stefan Bodewig wrote:
>> On 2013-12-30, Stefan Bodewig wrote:
>>> Compress 1.x is at Java5, personally I don't think Java6 would give us
>>> any benefits. I don't know about t
On Sun, Jan 26, 2014 at 8:13 AM, Stefan Bodewig wrote:
> On 2014-01-25, Damjan Jovanovic wrote:
>
>> On Fri, Jan 24, 2014 at 6:06 PM, Stefan Bodewig wrote:
>>> On 2013-12-30, Stefan Bodewig wrote:
>
>>>> Compress 1.x is at Java5, personally I don't think
7 8:03 GMT+01:00 Stefan Bodewig :
> Hi all,
>
> this is a heads-up that I intend to cut a RC for Compress 1.8 soon. We
> have accumulated a few bugfixes and at least COMPRESS-264 is pretty
> serious.
>
> I've already updated the website from trunk (basically to have the n
On 2014-02-27, Benedikt Ritter wrote:
> the project reports look good to me. Some package have low test coverage
> but I think you've already said that it's pretty hard to write tests for
> this areas of the code. PMD shows four violations. The first three look
> like they can be fixed easily.
No
It looks like this should be a smooth release :)
Gary
On Thu, Feb 27, 2014 at 2:03 AM, Stefan Bodewig wrote:
> Hi all,
>
> this is a heads-up that I intend to cut a RC for Compress 1.8 soon. We
> have accumulated a few bugfixes and at least COMPRESS-264 is pretty
> serious.
&
of this
> are the new get/setContentMethods methods in SevenZOutpuzFile and
> SevenZArchiveEntry along with the new SevenZMethodConfiguration class.
To summarize some discussion from IRC back to the list:
The main change is this one
<http://svn.apache.org/viewvc/commons/proper/compre
The default manager configuration in providers.xml registers the Tar
and Bzip2FileProvider conditionally based on commons compress classes.
For GzipFileProvider it uses unconditionally the java.util.zip package.
So I
***
SCM Changes:
Changed: bayard @ Wed 22 Aug 2007 07:20:20 -0700
Comment: Adding a '(Sandbox)' because it seems like a good idea
Files changed:
/commons/sandbox/compress/trunk/pom.xml ( 568621 )
/commons/sandbox/csv/trunk/p
*
Output:
[INFO] Scanning for projects...
[INFO]
----
[INFO] Building Compress (Sandbox)
[I
check it out via GIT:
http://projects.grobmeier.de/compress-redesign.git/
Your comments and your help is highly appreciated.
However, unfortunatly I cannot fix this issues in the repository,
cause I have no commit access.
Best regards,
Chris.
On Tue, Jun 17, 2008 at 11:02 AM, Emmanuel Bourg
://projects.grobmeier.de/compress-redesign.git/
Your comments and your help is highly appreciated.
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
What are the differences of th
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.git
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
>
> 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
ation
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.grobmeier.de/compress-redesign.git/
Your comments and your help is highly appreciated.
My comments, in no specific
- 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
ning up. Especially the testcases need
> some more love.
>
I have a bit time for cleaning up after my holidays. It would be nice to
move on with compress :-)
Best,
Chris
>
> cheers
> --
> Torsten
>
>
> ---
e borrowed from ant :)
Impossible! 8-)
OK, we've never been consistent with our notation and some committers
liked HN You probably don't find any in the zip package.
I've probably said this before. The compress classes have been
extracted from Ant and found their way into commons via Av
ate static Method c_setCompressedSizeMethod;
But that's commons compress code, Ant is clean. It seems like we could
update our code from the latest Ant source for the zip package.
Emmanuel Bourg
-
To unsubscribe, e-mail: [
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.
Hm ...indeed. But IMO the changeset stuff is where it a
try extends java.util.zip.ZipEntry
> {
> private static Method c_setCompressedSizeMethod;
>
>
> But that's commons compress code, Ant is clean.
And never had hungarian notation, I guess it was introduced somewhere
along the way (Avalon would be my best guess).
Stefan
-
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
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, 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
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
weird design decisions, too. :)
>
We had a discussion at this list long time before. If you are interested,
you may want to search the mailinglists.
>
>
> - Ant has a JarMarker class that extends ZipExtraField, is there an
>>>> equivalent ?
>>>>
>>> Could you
>
> >> 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 :
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.
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
>
>
> 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.
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
>
> 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 cre
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
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
>
>
> +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!
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
601 - 700 of 2077 matches
Mail list logo
