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
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
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
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
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
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=97526&projectId=176
Build statistics:
State: Ok
Previous State: Failed
Started at: Wed 18 Jun 2008 02:15:36 -0700
Finished at: Wed 18 Jun 2008 02:16:35 -0700
Total time: 58s
Build Trigger: Schedule
Build Number
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
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
>
> 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
>
> >> 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 I
>
> 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
Hi Brett,
which java version was being used so I can update the test matrix ...
Thanks in advance
Siegfried Goeschl
Brett Porter wrote:
My results:
Time: 49.106
OK (55 tests)
-bash-3.00$ uname -a
SunOS maven.zones.apache.org 5.10 Generic_127128-11 i86pc i386 i86pc
Thanks for all your work
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
1.5.0_15
2008/6/18 Siegfried Goeschl <[EMAIL PROTECTED]>:
> Hi Brett,
>
> which java version was being used so I can update the test matrix ...
>
> Thanks in advance
>
> Siegfried Goeschl
>
> Brett Porter wrote:
>>
>> My results:
>>
>> Time: 49.106
>>
>> OK (55 tests)
>>
>> -bash-3.00$ uname -a
>>
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
On Tue, Jun 17, 2008 at 1:13 PM, Siegfried Goeschl
<[EMAIL PROTECTED]> wrote:
> Hi Niall,
>
> I only have the same response I wrote six months ago ... :-)
>
> +) I can't make any promises but commons-exec is small enough to be
> maintained in the small hours when the family is asleep
> +) I'm not 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!
Hi,
I decided to create a new ticket (CODEC-69) rather than attach to
CODEC-8. The scope of CODEC-8 is somewhat broader (streaming for all
encoders/decoders in commons-codec!), and I don't think I have enough
time to take it that far.
The patch attached to CODEC-69 has JUnits added for many stre
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
At long last, I have prepared the preliminary
proposal. I'd like to have the support of Commons as
the sponsoring PMC. I'd also like it if I could get a
couple of mentors from the group as well. The current
proposal can be viewed at:
http://people.apache.org/~mbenson/flatfile-proposal/proposal
Because the findbugs results, as well as the minor
documentation issues that were identified, have
already been addressed in trunk, it probably doesn't
make any sense to release 1.3 only to follow it
immediately with 1.3.1 when the content of 1.3.1 is
already known before 1.3 is released. Does any
On 18/06/2008, Matt Benson <[EMAIL PROTECTED]> wrote:
> Because the findbugs results, as well as the minor
> documentation issues that were identified, have
> already been addressed in trunk, it probably doesn't
> make any sense to release 1.3 only to follow it
> immediately with 1.3.1 when the
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
On 18/06/2008, Matt Benson <[EMAIL PROTECTED]> wrote:
> At long last, I have prepared the preliminary
> proposal. I'd like to have the support of Commons as
> the sponsoring PMC. I'd also like it if I could get a
> couple of mentors from the group as well. The current
> proposal can be viewe
--- sebb <[EMAIL PROTECTED]> wrote:
> On 18/06/2008, Matt Benson <[EMAIL PROTECTED]>
> wrote:
> > At long last, I have prepared the preliminary
> > proposal. I'd like to have the support of
> Commons as
> > the sponsoring PMC. I'd also like it if I could
> get a
> > couple of mentors from th
On 6/18/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: jochen
> Date: Wed Jun 18 12:16:03 2008
> New Revision: 669256
>
> URL: http://svn.apache.org/viewvc?rev=669256&view=rev
> Log:
> PR: CODED-69
> Submitted-By: Julius Davies <[EMAIL PROTECTED]>
> Added the Base64InputStream an
That looks interesting, this kind of structure can still be found today
in ar and cpio archives used for deb and rpm packages. I also used this
style of file in inter bank communications a few years ago.
That would be awesome if the component was able to operate on binary
files too, you would
--- Emmanuel Bourg <[EMAIL PROTECTED]> wrote:
> That looks interesting, this kind of structure can
> still be found today
> in ar and cpio archives used for deb and rpm
> packages. I also used this
> style of file in inter bank communications a few
> years ago.
>
> That would be awesome if the
On Wed, Jun 18, 2008 at 10:18 AM, Matt Benson <[EMAIL PROTECTED]> wrote:
> At long last, I have prepared the preliminary
> proposal.
Pardon me if I missed some previous discussion, but I'm not finding anything
about "flatfile" in the archives.
Why is this heading for incubation? Given that you
On Wed, Jun 18, 2008 at 11:53 PM, Matt Benson <[EMAIL PROTECTED]> wrote:
> --- Emmanuel Bourg <[EMAIL PROTECTED]> wrote:
>
> > That looks interesting, this kind of structure can
> > still be found today
> > in ar and cpio archives used for deb and rpm
> > packages. I also used this
> > style of fi
35 matches
Mail list logo
