On 2009-02-11, Torsten Curdt tcu...@apache.org wrote:
I am also not so sure this really all that bad. I guess there are 3 scenarios
1: the archive standard is known to use a specific encoding
2: the encoding is specified inside the archive (which is similar to 1)
3: we have no clue about the
On 2009-02-11, sebb seb...@gmail.com wrote:
That seems likely to produce some confusion - would it not be better
to default to UTF-8?
Yes, that's been my initial question. Is it OK to have no default at
all or should we keep with UTF-8?
Given that ZipArchiveInputStream doesn't support
On 2009-02-11, sebb seb...@gmail.com wrote:
The Compress pom.xml does not specify what Java version is being
targetted.
Last week it was 1.4
Perhaps someone could add the source/target properties?
No idea how to do that and the POM reference didn't tell me either.
Please forgive the mvn
On 2009-02-12, Christian Grobmeier grobme...@gmail.com wrote:
Here it is:
https://issues.apache.org/jira/browse/SANDBOX-288
applied, thanks.
You have to check the compiler-plugin for the information:
On 2009-02-11, Ingo Rockel i...@grimmfrost.de 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
Hi,
Solaris contains some special code which allows people to mark jar
files executable and run them as if they were native commands. It
will only work for jars that contain the sequence 0xCAFE (in
big-endian order) somewhere at the beginning, which is achieved by
adding an extra field with that
Let me try to capture the various threads in SANDBOX-176 and from this
list into something we can draw conclusions from.
First some background:
==
when I implemented the ZIP classes for Ant, I was working from
InfoZIP's documentation of the format, not PKWARE's, I've now read
On 2009-02-13, Wolfgang Glas wolfgang.g...@ev-i.at wrote:
Stefan Bodewig schrieb:
Reading
===
The question is what ZipFile should assume as its default if neither
the EFS nor extra fields are present. This can be controlled by
setEncoding right now and defaults to the platform's
On 2009-02-15, Christian Grobmeier grobme...@gmail.com wrote:
I have improved the testcases for SANDBOX-183.
The patch is attached here:
https://issues.apache.org/jira/browse/SANDBOX-183
Four of the tests fail if I apply the patch:
Failed tests:
On 2009-02-13, Stefan Bodewig bode...@apache.org wrote:
I propose to modify JarArchiveOutputStream to add a JarMarker extra
field to the very first entry written to the stream.
done.
Stefan
-
To unsubscribe, e-mail: dev
I started to take some baby steps implementing it, in particular
On 2009-02-13, Stefan Bodewig bode...@apache.org wrote:
Currently I think the best default approach would be to use UTF-8 as
the default encoding and set the EFS bit since this will create
archives compatible with java.util.zip
On 2009-02-19, commons-compress development dev@commons.apache.org wrote:
Tests in error:
testDeleteFromAndAddToZip(org.apache.commons.compress.changes.ChangeSetTestCase)
Tests run: 51, Failures: 0, Errors: 1, Skipped: 0
I assume this is yet another test that need to be worked on and
On 2009-02-18, Wolfgang Glas wolfgang.g...@ev-i.at wrote:
Stefan Bodewig schrieb:
Wolfgang, you may notice a few minor tweaks to your original code. Do
you happen to have stand-alone tests for the Unicode extra fields
anywhere?
A rudimentary test is in my original patch as attached
On 2009-02-19, Stefan Bodewig bode...@apache.org wrote:
On 2009-02-18, Wolfgang Glas wolfgang.g...@ev-i.at wrote:
A rudimentary test is in my original patch as attached to SANDBOX-176.
I have refactored this test to the current SVN revision an attached to this
mail.
Thanks, I've modified
On 2009-02-18, Stefan Bodewig bode...@apache.org wrote:
UTF-8 is now the default for ZipArchiveOutputStream and ZipFile, EFS
support is not yet in.
Now it is. I combined Wolfgang's patch for EFS with one by TAMURA
Kent to Ant https://issues.apache.org/bugzilla/show_bug.cgi?id=45548
On 2009-02-20, Torsten Curdt tcu...@apache.org wrote:
If somebody provides a patch in JIRA and we commit it, do we
automatically add the submitter as a contributor to the POM (in
Ant-land we'd do so, well, not inside the POM, of course)?
Not sure there is a policy.
Thought so.
I've
On 2009-02-21, Henri Yandell flame...@gmail.com wrote:
On Fri, Feb 20, 2009 at 8:27 AM, Stefan Bodewig bode...@apache.org wrote:
On 2009-02-20, Torsten Curdt tcu...@apache.org wrote:
If somebody provides a patch in JIRA and we commit it, do we
automatically add the submitter as a contributor
On 2009-02-24, Henri Yandell flame...@gmail.com wrote:
On Mon, Feb 23, 2009 at 8:27 AM, Stefan Bodewig bode...@apache.org wrote:
On 2009-02-21, Henri Yandell flame...@gmail.com wrote:
The JIRA contribution report (sales pitch! :) ) can help here.
That sales pitch worked. Can I see
On 2009-02-24, Ralph Goers ralph.go...@dslextreme.com wrote:
Nothing in commons vfs changed. What broke it?
Hard to say. It could be a change in an underlying library.
It seems more likely - since it fixed itself - that it is some sort of
timing issue, though.
From the test's name I assume
On 2009-02-26, Jukka Zitting jukka.zitt...@gmail.com wrote:
I looked at the compress component in the sandbox and it's exactly
what we could use in Apache Tika, see [1].
If you pick up the latest code from Ant instead you'll see they are
the same 8-)
They even are used by projects during Gump
On 2009-02-26, s...@apache.org wrote:
Fix set() methods that do not actually work.
Ouch. Thanks!
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail:
On 2009-02-28, Christian Grobmeier grobme...@gmail.com wrote:
Additionally we have to:
- improve maven site stuff, which is a bit outdated now
Oh yes, true. I must admit that I'm at a total loss here since I
never used any mvn goal other than clean or package - so I'll have
some learning to
On 2009-02-28, Christian Grobmeier grobme...@gmail.com wrote:
Torsten (or any other) if you can't check this out now I will create
an issue for that and check it out later. Let me know.
I'd say create an issue and if possible attach a test.
Stefan
On 2009-03-01, Wolfgang Glas wolfgang.g...@ev-i.at wrote:
My understanding from previous discussion was, that we need a mode,
where file names not encodable by the chosen encoding are encoded in
UTF-8, which is in turn indicated by setting the EFS flag on the
likewise ZIP entry. (That's the
On 2009-02-28, Christian Grobmeier grobme...@gmail.com wrote:
I have improved ChangeSet stuff a bit. It now supports most common
usecases as described in the testcase.
The re-enabled tests pass for me, great.
svn revision 749332.
Stefan
On 2009-03-02, Stefan Bodewig bode...@apache.org wrote:
some cosmetics and commented out the only create Unicode field for
non-encodable paths part - svn revision 749342.
and 749344 - you misspet encoding in Simple8BitEncoding.java and I
didn't see it in time.
Stefan
On 2009-03-02, Wolfgang Glas wolfgang.g...@ev-i.at wrote:
...another small patch with even more javadoc typos and superfluent imports
fixed is attached.
svn rev 749524
Thanks
Stefan
-
To unsubscribe, e-mail:
On 2009-03-03, commons-compress development dev@commons.apache.org wrote:
Results :
Tests in error:
testDeleteDir(org.apache.commons.compress.changes.ChangeSetTestCase)
testDeleteFile(org.apache.commons.compress.changes.ChangeSetTestCase)
On 2009-03-02, Wolfgang Glas wolfgang.g...@ev-i.at wrote:
Stefan Bodewig schrieb:
On 2009-03-01, Wolfgang Glas wolfgang.g...@ev-i.at wrote:
1) Unicode extra fields are written for all ZIP entries and not only
for entries, which are not encodable by the encoding set to
ZipArchiveOutputStream
Surefire reports are linked from
http://vmgump.apache.org/gump/public/commons-sandbox/commons-compress-test/index.html
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail:
On 2009-03-03, Wolfgang Glas wolfgang.g...@ev-i.at wrote:
Stefan Bodewig schrieb:
On 2009-03-02, Wolfgang Glas wolfgang.g...@ev-i.at wrote:
Stefan Bodewig schrieb:
On 2009-03-01, Wolfgang Glas wolfgang.g...@ev-i.at wrote:
1) Unicode extra fields are written for all ZIP entries and not only
On 2009-03-03, Wolfgang Glas wolfgang.g...@ev-i.at wrote:
Stefan Bodewig schrieb:
On 2009-03-03, Wolfgang Glas wolfgang.g...@ev-i.at wrote:
Stefan Bodewig schrieb:
On 2009-03-02, Wolfgang Glas wolfgang.g...@ev-i.at wrote:
Acccording to my tests WinZip recognizes the EFS flag upon
reading
On 2009-03-04, sebb seb...@gmail.com wrote:
These all show errors of the form:
java.io.FileNotFoundException:
/home/continuum/data/working-directory/176/target/test-classes/test%20with%20spaces.txt
(No such file or directory)
at java.io.FileInputStream.open(Native Method)
at
On 2009-03-04, Wolfgang Glas wolfgang.g...@ev-i.at wrote:
Hello Stefan reviewed you code and found out, that you did not
strictly use the same encoding for filenames and comments in one
entry.
Good catch, thanks!
svn rev 750310
Stefan
On 2009-03-06, sebb seb...@gmail.com wrote:
On 05/03/2009, bode...@apache.org bode...@apache.org wrote:
URL: http://svn.apache.org/viewvc?rev=750313view=rev
Log:
make tests pass on Linux
However, they now fail on Windows (and compilation fails on Java
1.4/1.5, but I fixed that).
Sorry
On 2009-03-06, Stefan Bodewig bode...@apache.org wrote:
On 2009-03-06, sebb seb...@gmail.com wrote:
I'm not sure that getResource() is the correct method to use here.
Well, it works great for files that don't contain spaces in their name
8-)
Looking into AbstractTestCase it explicitly adds
On 2009-03-06, Christian Grobmeier grobme...@gmail.com wrote:
Could anybody using Eclipse please check whether the appended trivial
patch causes problems there?
Your patch works for me with Eclipse Ganymede and Mac OSX 10.5.
It should as long as your current working directory is set
On 2009-03-06, sebb seb...@gmail.com wrote:
On 06/03/2009, Stefan Bodewig bode...@apache.org wrote:
On 2009-03-06, sebb seb...@gmail.com wrote:
Adding back the .getClassLoader() stage improves matters,
That really isn't supposed to make any difference, strange.
Class.getResource() makes
Hi all,
before I start a vote, let's see whether everything is in place.
http://wiki.apache.org/commons/CommonsEtiquette says:
* compliance with policies:
Just now I've run RAT and it flags src/site/xdoc/style/project.css
as well as a few test files. I could fix the CSS (other proper
On 2009-03-09, sebb seb...@gmail.com wrote:
On 09/03/2009, Stefan Bodewig bode...@apache.org wrote:
Hi all,
before I start a vote, let's see whether everything is in place.
http://wiki.apache.org/commons/CommonsEtiquette says:
* compliance with policies:
Just now I've run RAT
On 2009-03-10, sebb seb...@gmail.com wrote:
On 10/03/2009, bode...@apache.org bode...@apache.org wrote:
standard NOTICE header, a bit of whitespace
The header is specifically NOT required for NOTICE files, which is why
RAT does not insist on adding one.
The nice thing about policies is
On 2009-03-12, Christian Grobmeier grobme...@gmail.com wrote:
Hi all,
since everybody seems to agree to promoting compress I collected
several todos.
I'm a bit swamped at ${work} right now, but hope to prepare a PROPOSAL
and start a formal vote tomorrow at latest.
* Gump: I don't see
Hi all,
since I'm unsure whether a PROPOSAL is needed for existing sandbox
components as old as compress I tried to be save and created one based
on the old Jakarta template:
http://svn.apache.org/viewvc/commons/sandbox/compress/trunk/PROPOSAL.txt?view=markuppathrev=753102
RAT only flags a few
On 2009-03-13, Stefan Bodewig bode...@apache.org wrote:
http://svn.apache.org/viewvc/commons/sandbox/compress/trunk/PROPOSAL.txt?view=markuppathrev=753102
The compress component shall become a proper Commons component:
[X] +1 Yes
[ ] -1 No
Stefan
On 2009-03-13, Niall Pemberton niall.pember...@gmail.com wrote:
+1 from me.
Thanks Niall, I was already fearing the vote would fail since Torsten
is on vacation so he won't be able to vote either.
If only pmc members planning to contribute vote +1 to promotions then
we should probably shut
On 2009-03-16, sebb seb...@gmail.com wrote:
I've not looked into this yet, but I think we can have two Lang builds
in Gump, one for the new stuff, and another for other projects.
Easily, yes.
Is there a branch that should be used by project that are likely to be
broken by the changes in lang?
On 2009-03-16, Henri Yandell flame...@gmail.com wrote:
Personally I think failing is good and we'll learn lots from it. I'd
like to keep trunk until the consumer community indicate it's a pain
point.
Right now it doesn't look as if any of the projects with many
dependees was affected. So the
On 2009-03-17, Christian Grobmeier grobme...@gmail.com wrote:
it looks like all the world is meeting at the conference except myself :-)
A pity.
However, I think developing at the hackathon is a quick development,
Since I won't attend the hackathon (no time for a full week off), I
don't
On 2009-03-17, sebb seb...@gmail.com wrote:
On 17/03/2009, Christian Grobmeier grobme...@gmail.com wrote:
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
On 2009-03-17, Christian Grobmeier grobme...@gmail.com wrote:
Hi
I could not test it with a general working testcase, since this is a
platform problem and i have only OSX.
I have written some rudimentary tests that pass on Windows.
can those test run successfully on *NIX too? (Gump is
On 2009-03-17, Jörg Schaible joerg.schai...@gmx.de wrote:
Stefan Bodewig wrote at Dienstag, 17. März 2009 06:00:
This works great for Ant built projects but doesn't work at all for
Maven built ones since those additional jars would never be used by
Maven unless they are listed in the POM
On 2009-03-17, Jörg Schaible joerg.schai...@gmx.de wrote:
I always assumed that Gump does not take care about the Maven deps,
since it uses its own descriptors.
That's the theory and it works for build tools that support this
use-case (read: Ant).
AFAIK there is no way to make mvn supply more
On 2009-03-17, Jörg Schaible joerg.schai...@gmx.de wrote:
Hmmm. Actually it is possible if the Gump descriptor could be used to map a
specific artifact to a different one, e.g. commons-lang:commons-lang:* to
org.apache.commons:commons-lang-backcomp:3.x.
Yes, that could work, but it still
Hi,
some of the classes inherited from Ant contain protected fields that
are only there for backwards compatibility reasons.
For example ZipOutputStream in Ant used to extend
java.util.zip.DeflaterOutputStream in Ant 1.4 which exposes the
Deflater as a non-final protected field - when we changes
On 2009-03-18, Stefan Bodewig bode...@apache.org wrote:
I'd like to remove some fields, make them private or final and maybe
move some methods around before our first release. In particular:
I just saw sebb's patch attached to SANDBOX-294 and he seems to agree
with most of my points
On 2009-03-18, sebb seb...@gmail.com wrote:
On 18/03/2009, Stefan Bodewig bode...@apache.org wrote:
Gump doesn't provide the POMs, it uses them of the original
repository.
Maybe the Gump descriptor syntax could be extended to provide a means
of specifying replacements to be made
Is commons-configuration going to be adapted to the commons-lang
changes or are we at a point where we need to figure out a way to
isolate commons-configuration from lang's trunk?
Stefan
-
To unsubscribe, e-mail:
On 2009-03-19, Christian Grobmeier grobme...@gmail.com 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
Hi all,
I'm happy to announce that compress has been promoted to a proper
component.
The vote ended with no -1s and 13 +1s (I didn't assert all of these 13
were binding, but know that many more than 3 are).
Hi,
the things to do:
* move in svn
I'll take care of it and modify the externals for trunks-sandbox and
trunks-proper
* different parent POM
parent
groupIdorg.apache.commons/groupId
artifactIdcommons-parent/artifactId
version11/version
/parent
should be correct, at
On 2009-03-20, Christian Grobmeier grobme...@gmail.com wrote:
as far as I know you have to apply a DOAP file.
I'd like to defer that to the point when we have the site in place as
well since we'd need to change URLs inside the DOAP file after that
anyway.
Stefan
On 2009-03-23, Siegfried Goeschl siegfried.goes...@it20one.at wrote:
'mvn site' fails due to a missing checkstyle.xml in pom.xml - is that
file missing or the pom wrong?
AFAICT there has never been such a file.
I've just now commented out the checkstyle plugin, hope it helps to
get you
On 2009-03-24, Dennis Lundberg denn...@apache.org wrote:
Stefan Bodewig wrote:
* setup a new JIRA project 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.
JIRA is now set up to handle
On 2009-03-24, Dennis Lundberg denn...@apache.org wrote:
Niall Pemberton wrote:
I updated the main commons site to move compress from the Sandbox to
proper page. Looks like Dennis corrected the urls, so I have deployed
a new version of compress site under proper - should be there after
the
On 2009-03-25, Jörg Schaible joerg.schai...@gmx.de wrote:
BTW: What is the difference in Gump's project descriptor between the
optional and depend tags?
If the project you depend on doesn't build in Gump, your project won't
be built at all if you use depend and will still build if you use
On 2009-03-24, Torsten Curdt tcu...@apache.org wrote:
Personally I am not a big fan of checkstyle enforcement at all.
I can perfectly well live without it as well.
Stefan
-
To unsubscribe, e-mail:
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
On 2009-03-26, Christian Grobmeier grobme...@gmail.com wrote:
This should make sure that CPIO classes work like all the other classes.
Thanks.
I've moved the finish() call in close() inside the !closed branch
since otherwise finish's ensureOpen would cause trouble for repeated
calls to close
On 2009-03-26, Jukka Zitting jukka.zitt...@gmail.com wrote:
The commons-compress NOTICE file currently contains the following entries:
Original BZip2 classes contributed by Keiron Liddle
kei...@aftexsw.com, Aftex Software to the Apache Ant project
Original Tar classes from
On 2009-03-26, bode...@apache.org wrote:
support as much as possible of ZipFile as a stream can do in
ZipArchiveInputStream, COMPRESS-47
This is Harmony's ZipInputStream combined with compress's parsing of
the local file header - so we do get encoding support in
ZipArchiveInputStream.
I need
On 2009-03-26, Torsten Curdt tcu...@apache.org 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
On 2009-03-27, tcu...@apache.org wrote:
fixed the testcase
You didn't, fails for me on Linux (and apparently inside Gump as well).
I intended to update the site, but will hold back now because I don't
want the surefire report to show failing tests.
Stefan
On 2009-03-28, sebb seb...@gmail.com wrote:
pReading entries from an ar archive:/p
source![CDATA[
ArArchiveEntry entry = (ArArchiveEntry) arInput.getNextEntry();
byte[] content = new byte[entry.getSize()];
LOOP UNTIL entry.getSize() HAS BEEN READ {
I thought the idea was that the
On 2009-03-28, sebb seb...@gmail.com wrote:
On 28/03/2009, Stefan Bodewig bode...@apache.org wrote:
On 2009-03-28, sebb seb...@gmail.com wrote:
I thought the idea was that the ArchiveInputStreams would not allow
one to read past the end of the entry, so one can just read until
read
your API suggesteions sound useful.
On 2009-03-30, sebb seb...@gmail.com wrote:
On 29/03/2009, sebb seb...@gmail.com wrote:
On 29/03/2009, sebb seb...@gmail.com wrote:
The current ChangeSet API allows for:
deletion of entries by name
The same method call is currently used for both deleting
I think I see why Gump's mvn repository proxy doesn't work here - it
currently doesn't work for group-ids that contain dots.
Do you want me to turn off nags until this gets fixed (shouldn't take
longer than a few days, I hope)?
Stefan
On 2009-03-30, sebb seb...@gmail.com wrote:
The abstract parent class for archive output streams has the method
putArchiveEntry(ArchiveEntry)
but all the implementations - apart from Ar - also define the specific method
putNextEntry(xxxArchiveEntry) where xxx = Zip, Jar, etc.
Do we
On 2009-03-30, sebb seb...@gmail.com wrote:
What about the corresponding getNextxxxEntry() methods?
I suppose they do avoid a cast.
Yes, in one case (tar IIRC) they have been explicitly asked for via
JIRA.
Stefan
-
To
On 2009-03-30, sebb seb...@gmail.com wrote:
Might it not be better to throw an Exception if methods are called out
of sequence?
We are pretty inconsistent here. In general I agree it would be
better to throw an exception, but we seem to swallow other errors in
other classes.
Stefan
On 2009-03-30, sebb seb...@gmail.com wrote:
On 30/03/2009, Stefan Bodewig bode...@apache.org wrote:
On 2009-03-30, sebb seb...@gmail.com wrote:
Might it not be better to throw an Exception if methods are called out
of sequence?
We are pretty inconsistent here. In general I agree it would
On 2009-03-30, sebb seb...@gmail.com wrote:
On 30/03/2009, Stefan Bodewig bode...@apache.org wrote:
On 2009-03-30, sebb seb...@gmail.com wrote:
What about the corresponding getNextxxxEntry() methods?
I suppose they do avoid a cast.
Yes, in one case (tar IIRC) they have been explicitly
On 2009-03-31, s...@apache.org wrote:
URL: http://svn.apache.org/viewvc?rev=760390view=rev
Log:
Set some attributes from the File
public ZipArchiveEntry(File inputFile, String entryName) {
this(entryName);
+ setSize(inputFile.length());
+
On 2009-03-31, sebb seb...@gmail.com wrote:
On 31/03/2009, Stefan Bodewig bode...@apache.org wrote:
setSize is dangerous here since it may very well 0 for directories
on Unix like systems.
Oops!
However it should be OK for regular files, no?
I hope so. I recall some problems
On 2009-03-31, Ralph Goers ralph.go...@dslextreme.com wrote:
On Mar 31, 2009, at 1:59 AM, Stefan Bodewig wrote:
I did not have the necessary permission to deploy to
people.apache.org, so I deployed the snapshot to the new M2 repo at
repository.apache.org. However, I commons configuration
On 2009-04-02, sebb seb...@gmail.com wrote:
So I'd like to rename the TarUtils getXXX() methods to formatXXX()
instead, as that is what the methods actually do - they format the
input long or stringbuffer into a byte buffer.
Also, TarArchiveEntry mostly uses StringBuffer rather than String.
Now that commons-configuration gets the latest and greates vfs it also
gets the latest of Xalan and we are back to this failure
All errors I checked look like this one
On 2009-04-07, Jörg Schaible joerg.schai...@gmx.de wrote:
Stefan Bodewig wrote at Dienstag, 7. April 2009 11:34:
On 2009-04-07, Gump iss...@commons.apache.org wrote:
[snip]
This happens because I've set maven.test.skip to true (since one of
VFS' unit tests is failing in Gump and I wanted
On 2009-04-07, Gump iss...@commons.apache.org wrote:
Missing:
--
1) org.apache.commons:commons-vfs:test-jar:tests:2.0-SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file
Hi Mladen,
On 2009-04-07, mt...@apache.org wrote:
URL: http://svn.apache.org/viewvc?rev=762766view=rev
Log:
Opps. Now you know from where this class originated :)
-/*
- * SIGHT - System information gathering hybrid tool
- *
- * Copyright(c) 2007 Red Hat Middleware, LLC,
...
- *
- *
On 2009-04-07, Mladen Turk mt...@apache.org wrote:
Stefan Bodewig wrote:
Hi Mladen,
In the later case well need a software grant for it since we cannot
simply fork a LGPLed code base under the Apache License.
It's not a fork, cause it was never released.
This was just a testing code
Christian Grobmeier has been elected as a new Commons committer about
two weeks ago and this has been his first commit
On 2009-04-07, grobme...@apache.org wrote:
Author: grobmeier
Date: Tue Apr 7 16:56:00 2009
New Revision: 762849
Welcome!
Stefan
On 2009-04-09, Christian Grobmeier grobme...@gmail.com wrote:
Sine I really don't like those System.err.println stuff I would like
to remove it from the classes including the debug flag.
+1
Stefan
-
To unsubscribe, e-mail:
On 2009-04-14, Christian Grobmeier grobme...@gmail.com wrote:
Open and unscheduled Issues are:
* COMPRESS-62 Need many more test cases to check that can read
real archives
* COMPRESS-64 Are the public finish() methods ArchiveOutputStream
implementations necessary and safe?
On 2009-04-27, sebb seb...@gmail.com wrote:
Just remembered - what about ZipArchiveInputStream.useUnicodeExtraFields?
This field is currently unused - what are the plans for it?
It should never have been unimplemented at all 8-)
This was the last piece I wanted to do while working on the code
testCpioUnarchive fails when building from the source tarball on
Windows because test1.xml has Unix linefeeds and thus is four bytes
shorter than expected - no reason to block the relase for me.
All my other tests passed.
There shouldn't be md5/sha1 checksums for the PGP signatures (they
On 2009-05-18, sebb seb...@gmail.com wrote:
On 15/05/2009, Oliver Heger oliver.he...@oliver-heger.de wrote:
I think md5 checksums are required for all artifacts. They are currently
missing.
Agreed.
Could perhaps add sha1 as well, but not essential
md5s and sha1s are now there and match.
Hi,
I've started to implement a commons-compress based antlib over in Ant
land
https://svn.apache.org/repos/asf/ant/sandbox/antlibs/compress/trunk/
and just realized we don't have a common getLastModified() method in
ArchiveEntry - maybe we should have.
What seems to be worse is that we don't
On 2009-07-31, Emmanuel Bourg ebo...@apache.org wrote:
Stefan Bodewig a écrit :
I've started to implement a commons-compress based antlib over in Ant
land
https://svn.apache.org/repos/asf/ant/sandbox/antlibs/compress/trunk/
Nice! Do you plan to replace the archive/compress tasks in Ant
On 2009-08-01, Emmanuel Bourg ebo...@apache.org wrote:
Stefan Bodewig a écrit :
That's what I assume as well, I'm just hoping that anybody else would
know for sure before I fix it.
I created an archive with GNU ar to check the timestamp, I confirm
it's in seconds.
Thanks for the check
Hi,
over in Ant land we've received a bug report that Ant's ftp task
wouldn't compile against commons-net 2,0 because the IMAGE_FILE_TYPE
constant was removed from the FTP class.
Given that trunk still has that constant, is trunk in net sort of
obsolete and we should consider one of the branches
501 - 600 of 1182 matches
Mail list logo
