On 2013-12-20, Gary Gregory wrote:
How about using the current version of FB, 2.5.3?
OK, I upgradede findbugs, removed the methods from JarArchiveEntry and
commented the new warnings findbugs emits now (default encoding in
places where we explicitly want to use it).
Hi
even thouhg Gump stopped nagging, it still works. Tika is built by Gump
and they have a test they call testUnsupportedZipCompressionMethod in
which they seem to use an archive created with an IMPLODED entry.
This test started to fail when Emmanuel added support for IMPLODE but
unfortunately
On 2013-12-22, sebb wrote:
On 22 December 2013 07:45, Stefan Bodewig bode...@apache.org wrote:
http://vmgump.apache.org/gump/public/tika/tika-parsers-test/gump_file/org.apache.tika.parser.pkg.ZipParserTest.txt.html
Of course it is possible the archive isn't real and they used a
hex-editor
On 2013-12-22, Stefan Bodewig wrote:
I'll try to locate the archive they use later and see whether it looks
genuine but maybe somebody from tika is lurking here and can shed some
light.
The archive is real, InfoZIP's unzip is willing to extract it without
any errors. I've created unit tests
On 2013-12-22, Emmanuel Bourg wrote:
Le 22/12/2013 12:40, Stefan Bodewig a écrit :
The archive is real, InfoZIP's unzip is willing to extract it without
any errors. I've created unit tests from it with svn revision 1552980 -
not sure when I'll find time to analyze the error.
The issue
Hi,
I've started to write a tiny amount of code for 2.0 to get things moving
(more on this later) and have already reached a point where Java7 may
make a difference.
I'm trying to define an API for attributes beyond the set offered by
ArchivEntry so far - many (AR, ARJ, CPIO, ZIP, TAR, DUMP) of
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 expected there, but we
should
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 code has been replaced in plexus
On 2014-01-02, Gary Gregory wrote:
Sounds like an OS permission issue with executables. Can we use Maven to
create the right file permissions for sh files in a tar/zip?
Assuming you are using the assembly plugin, then the answer is yes:
On 2014-01-02, sebb wrote:
AFAIK zip does not support permissions.
InfoZIP does and so does Ant (or Commons Compress ;-). Not sure about
the assembly plugin but I'd assume it supports it as well.
Stefan
PS: permissions in ZIPs are the main reason I started to write the
org.apache.tools.zip
Hi,
putting the exact representation of an archive entry aside I've put down
an idea of the API for reading and writing archives together with a POC
port of the AR classes for this API. All is inside
http://svn.apache.org/repos/asf/commons/proper/compress/branches/compress-2.0/
The port doesn't
On 2014-01-09, Benedikt Ritter wrote:
scm
-connectionscm:svn:
http://svn.apache.org/repos/asf/commons/proper/compress/trunk/connection
-developerConnectionscm:svn:
https://svn.apache.org/repos/asf/commons/proper/compress/trunk
/developerConnection
-
Hi all
current trunk contains two new read-only compression algorithms but more
importantly it fixes serious bugs in the tar and 7z packages. As
indicated a few weeks ago a new release is overdue.
Compress 1.7 RC1 is available for review here:
On 2014-01-11, Oliver Heger wrote:
There is a problem with the source distribution: It deflates in a
directory commons-compress-1.6-src; so here the version number is
wrong. Not sure whether this is blocking or not - in any case, it is
confusing.
Ouch. Emmanuel told me I forgot to update
On 2014-01-11, Gary Gregory wrote:
The reports look good BUT I think the NEW code should have better code
coverage. There seems to be some non-trivial code that is not tested
at all.
AFAICS this is mostly handling cases that are difficult to create test
data for.
* Snappy with literals
Compress holds a package that is public as an implementation detail but
whose API isn't meant for public consumption. The javadocs of said
package state this in bold letters.[1]
Current trunk will even go further and hide the package from javadoc,
but the only class inside is still refered to by
On 2014-01-12, Stefan Bodewig wrote:
I'm a bit torn on this and since I'll re-roll a new RC anyway I'd like
to see what others think about hiding internal packages.
I've unhid it again and strengthened the may change warning as Sebb
suggested. Making things explicit feels better to me
Hi all
compared to RC1 there is no code change only the Javadocs of the
_internal package are even more discouraging and the directory tree
insite the tarballs/zips should hold the correct version number.
Compress 1.7 RC2 is available for review here:
thanks for the review and the vote.
On 2014-01-17, Benedikt Ritter wrote:
One minor thing I've noticed is, that the Build-By MANIFEST header is set
to stefan. I've learned that it should be set to you're Apache ID.
Well, this must have been that way for all releases I've ever
created. :-)
If
On 2014-01-17, Emmanuel Bourg wrote:
If you build the release from your son's account (or if you have
exotic tastes) you may end up with a 'Build-By: spacepirate' field in
the manifest, which is a bit embarrassing.
Now that's an idea. So I'll throw in a bit of desinformation with
future
Hi,
with +1s by Benedikt Ritter, Gary Gregory, Emmanuel Bourg, Phil Steitz,
Oliver Heger, Jörg Schaible and an implicit +1 by myself the vpte has
passed.
I'll start publishing the stuff and give the mirrors a bit of time
before updating the site and sending out the release announcement.
Thanks
information on Commons Compress, including instructions
on how to submit bug reports, patches, or suggestions for improvement,
see the Apache Commons Compress website:
http://commons.apache.org/compress/
Stefan Bodewig, on behalf of the Apache Commons community
-BEGIN PGP SIGNATURE-
Version
On 2014-01-22, Damjan Jovanovic wrote:
On Wed, Jan 8, 2014 at 4:41 PM, Stefan Bodewig bode...@apache.org wrote:
* Checked vs Unchecked exceptions
I would love to make ArchiveInput be an Iterator over the entries but
can't do so as the things we'd need to do in next() might throw
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 to me that Android
On 2014-01-25, Damjan Jovanovic wrote:
On Fri, Jan 24, 2014 at 6:06 PM, Stefan Bodewig bode...@apache.org 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
Hi
while pondering the API of Compress 2.x I already moaned about the lack
of decorator support in Channels, in particular pushback would be needed
in Compress in many places, but also stuff like counting, verifying
checksums and other Filter*Stream stuff.
When I started to look around I didn't
On 2014-01-27, Benedikt Ritter wrote:
I've planned to do some work on IO after [lang] 3.3, but you know how
it often turn's out with my plans ;-) so I cannot promise anything.
tell me - I'll go MIA for most of the next two or three weeks, I'm
afraid.
One thing I don't understand is: are you
On 2014-02-06, Mark Thomas wrote:
The FileUpload 1.3.1 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/fileupload/ (r4317)
Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-1005/
Details of changes since 1.3
On 2014-02-20, Benedikt Ritter wrote:
I'd like to call a vote for moving Commons Attributes to dormant.
Reasons:
- years have passed since the last real activity in attributes [1].
- the last release is from 2006.
- the code is pre Java 5.
+1
Stefan
On 2014-02-21, Mark Thomas wrote:
The Pool 2.2 RC2 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/pool/ (r4457)
Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-1009
Details of changes since 2.1 are in the
On 2014-02-26, Mark Thomas wrote:
I'm wondering what to do about @since markers. As DBCP2 is in a
completely new package, arguably everything is new for this release. The
existing @since markers don't make a lot of sense. Therefore, I am
currently considering removing all @since markers from
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 new
skin online) so you can already have a look at the reports.
Before
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.
Not
On 2014-02-27, luc wrote:
Is this failure expected? I am running the tests suite on a Linux
computer, maybe MicrosoftTagTest is windows-specific?
all tests pass for me:
$ uname -a
Linux brick 3.5.0-46-generic #70-Ubuntu SMP Wed Jan 8 18:40:46 UTC 2014
x86_64 x86_64 x86_64 GNU/Linux
$ java
Apart from the bugfixing we've added better support for 7z compression
methods - you can now chose a stack of more than one method when writing
(this has always been possible when reading), pass options to the
methods and use different configurations per entry. The core of this
are the new
Hi,
I've managed to implement the major BCJ filters for 7z (special filters
for native executables) by simply invoking the XZ for Java
implementations for it. This is needed for COMPRESS-257.
Unfortunately there is a bug in XZ for Java that has already been fixed
in git. When using a released
On 2014-02-28, sebb wrote:
Can Compress catch the specific Assertion Error and convert it to a
message that explains the issue? Perhaps even provide a link to a
Wiki FAQ?
not without catching all AssertionErrors
java.lang.AssertionError: null
at
On 2014-02-28, Gary Gregory wrote:
Do we have any idea WRT a new release of XZ?
I've reported the problem a few hours ago and Lasse fixed it within
minutes. This single line change is the only change since the 1.4
release cut six or seven month ago.
Not sure whether he'd like to create a new
On 2014-02-28, s...@apache.org wrote:
Add serialVersionUID
to a private inner class that is a subclass of HashMap.
Why?
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail:
On 2014-02-28, sebb wrote:
On 28 February 2014 17:47, Stefan Bodewig bode...@apache.org wrote:
On 2014-02-28, sebb wrote:
Alternatively, can Compress detect the XZ version and refuse to run
BCJ, again with suitable message?
No way short of parsing the OSGi attributes from the manifest
On 2014-03-01, sebb wrote:
On 1 March 2014 05:57, Stefan Bodewig bode...@apache.org wrote:
On 2014-02-28, s...@apache.org wrote:
Add serialVersionUID
to a private inner class that is a subclass of HashMap.
Why?
Eclipse complained; it won't do any harm.
Sure not, I was just curious
On 2014-03-02, sebb wrote:
On 1 March 2014 19:53, Matt Benson gudnabr...@gmail.com wrote:
I've said it before: doocracy. If someone wants to take on the work to
provide 1.5 support, they've widened the audience of the component, which
should be seen as a win if it didn't cause anyone else a
Hi all
I talked about cutting Compress 1.8 in particular because of
COMPRESS-264 but delayed it waiting for a new XZ for Java release.
Compress 1.8 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/compress/
(svn revision 4610)
Maven artifacts are
On 2014-03-09, Oliver Heger wrote:
When building with Java 1.5 I get the test failures below (this was
already the case for the previous releases, so probably no reason to
worry about).
It looks as if LZMA2 requires a lot of memory, all the failing tests are
using LZMA2 with default setting.
The vote has passed with +1s by
Emmanuel Bourg
Oliver Heger
Luc Maisonobe
Gary Gregory
Jörg Schaible
and no other votes.
I'll proceed with publishing the release artifacts but it may take a bit
longer than usual to update the site as I'm traveling right now. Should
be done by Friday the
Commons Compress website:
http://commons.apache.org/compress/
Stefan Bodewig, on behalf of the Apache Commons community
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAlMhRewACgkQohFa4V9ri3JILACgqpPksDdKQPHq+U9gAQ2yZYTA
OqcAnRQcpMPZT6mFHchKTUGkYzzCsw/i
=NgWC
-END PGP
On 2014-04-03, ebo...@apache.org wrote:
Don't use '_' as an identifier to avoid a compiler warning with Java 8
why is Java8 complaining?
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional
On 2014-04-03, Benedikt Ritter wrote:
I didn't now that '_' is a valid identifier at all.
That's a different point. :-)
_ is used as an identifier in many funtional languages to mean any
argument, I don't care for it anyway when you need to have an argument
for a certain contract but won't use
On 2014-04-03, Emmanuel Bourg wrote:
Le 03/04/2014 10:27, Stefan Bodewig a écrit :
why is Java8 complaining?
I don't know, it says '_' is deprecated and may become illegal in the
future. I guess '_' may be used for a new language feature.
OK, thanks, didn't know that. I've by noe found
On 2014-04-03, Benedikt Ritter wrote:
2014-04-03 12:05 GMT+02:00 Stefan Bodewig bode...@apache.org:
On 2014-04-03, Benedikt Ritter wrote:
I didn't now that '_' is a valid identifier at all.
That's a different point. :-)
_ is used as an identifier in many funtional languages to mean any
On 2014-04-03, Emmanuel Bourg wrote:
http://openjdk.5641.n7.nabble.com/Warning-about-single-underscore-identifier-td145974.html
They are deprecating the use of _ for method argument names so that
one day I may be able to use it for the exact same purpose I've done so
for :-)
Stefan
On 2014-04-06, Benedikt Ritter wrote:
Note that we're still having problems with Java 8 / DocLint. mvn install
works (thanks to the fixes Niall has made) but mvn site still fails because
the test code contains malformed JavaDoc comments. I've documented this
problem on the main page (and hope
On 2014-04-23, Ate Douma wrote:
But it would be great to hear who *might* be interested in
participating in such a Apache Commons track, about what
topic/component you'd like to talk about, etc. Just to determine if
this might be a feasible setup, already next ApacheCon or maybe
sometimes
Hi all,
two months since the last release and we've accumumlated a few bugfixes,
most notably in tar (again, one would expect that part of the code base
to be the most mature). I'd like to create a new release.
We have changed the POM to mark our dependency on XZ for Java as
optional but still
Hi all,
delayed because I wanted to wait for mails to arrive again.
Compress 1.8.1 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/compress/
(svn revision 5300)
Maven artifacts are here:
On 2014-05-11, Gary Gregory wrote:
-1 There are 58 Javadoc failures under Java 8.
So we'll need 4 +1s in this case :-)
Please not that apart from some missing @params and @returns there is a
clear bug in Java 8's javadoc that I don't think we can work around.
On 2014-05-11, Stefan Bodewig wrote:
On 2014-05-11, Gary Gregory wrote:
-1 There are 58 Javadoc failures under Java 8.
So we'll need 4 +1s in this case :-)
Nonsense. 3 +1s and more +1s than -1s, that's all.
Stefan
On 2014-05-11, Stefan Bodewig wrote:
Hi all,
delayed because I wanted to wait for mails to arrive again.
Compress 1.8.1 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/compress/
(svn revision 5300)
Maven artifacts are here:
https
On 2014-05-11, Emmanuel Bourg wrote:
There is a typo in the changes report:
ArchiveStreams now validate there is a current entry before rreading or
writing entry data.
Thanks, will fix the site post-release.
Stefan
-
To
Hi all
with a -1 by Gary Gregory and +1s by Emmanuel Bourg, Luc Maisonobe, Phil
Steitz and myself the vote has passed.
I'll publish all artefacts and update the site/announce the release
after the mirrors had time to catch up.
Thanks
Stefan
The dependency on org.tukaani:xz is now marked as optional.
For complete information on Commons Compress, including instructions
on how to submit bug reports, patches, or suggestions for improvement,
see the Apache Commons Compress website:
http://commons.apache.org/compress/
Stefan Bodewig, on behalf
On 2014-07-25, Gary Gregory wrote:
It's that or we agree never to publish a SNAPSHOT site.
For the record, I do value SNAPSHOT sites so we can also show what we
are working on. I'm not convinced we need to enforce the same policy
for all components. OTOH I don't feel strong enough about it to
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 a href=[EMAIL PROTECTED]Stefan Bodewig/a
If anybody could remove
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 considered
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.
The jar tool
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-daemon has an issue affecting its community integration.
This issue
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-launcher has an issue affecting its community integration.
This issue
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-xmlio has an issue affecting its community integration.
This issue
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-cli has an issue affecting its community integration.
This issue affects
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-el has an issue affecting its community integration.
This issue affects
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-math has an issue affecting its community integration.
This issue
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-net has an issue affecting its community integration.
This issue affects
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-chain has an issue affecting its community integration.
This issue
On Mon, 30 Jun 2008, Martin Oberhuber [EMAIL PROTECTED] wrote:
Is anybody addressing this Gump Nag message for commons-net
already:
It was caused by broken XML in xml-apis' descriptor and fixed a few
weeks ago.
Stefan
-
To
Hi all,
I couldn't find a JIRA for compress so I'm posting it here.
We had a bug report against Ant's ZipOutputStream that showed that the
class had a way worse performance compared to java.util.zip's cousin
when it was used to compress big files. See
On Wed, 16 Jul 2008, sebb [EMAIL PROTECTED] wrote:
On 16/07/2008, Stefan Bodewig [EMAIL PROTECTED] wrote:
I couldn't find a JIRA for compress so I'm posting it here.
Compress is currently in the Sandbox.
Thanks, I didn't realize that the sandbox had a JIRA section of its
own.
https
Gump still tried to use a Maven 1.x build, but that doesn't work
anymore.
I've switched the descriptor to use Maven 2 instead, expect a few more
nags until we have the correct file name of the generated jar
(unfortunately Gump cannot enforce this in mvn anymore) and I am
satisified with the
On Wed, 8 Oct 2008, sebb [EMAIL PROTECTED] wrote:
Given that compress is in the sandox, it seems strange that it affects
so many projects.
Do they really all depend on compress?
Transitively, commons-vfs depends on commons-compress
On Wed, 8 Oct 2008, sebb [EMAIL PROTECTED] wrote:
On 08/10/2008, Stefan Bodewig [EMAIL PROTECTED] wrote:
On Wed, 8 Oct 2008, sebb [EMAIL PROTECTED] wrote:
Given that compress is in the sandox, it seems strange that it affects
so many projects.
Do they really all depend
On Fri, 17 Oct 2008, Hendrik Maryns [EMAIL PROTECTED] wrote:
ant -diagnostics
--- Ant diagnostics report ---
Apache Ant version 1.7.0 compiled on June 7 2008
---
Implementation Version
---
core tasks
On 2008-11-10, Stefan Bodewig [EMAIL PROTECTED] wrote:
I'll look into the proxy logs to see whether something unexpected is
being downloaded.
INFO: Redirecting via client connector to: http://repo1.maven.org/maven2/org/apa
che/maven/plugins/maven-plugins/11/maven-plugins-11.pom
Nov 10, 2008 12
On 2008-11-10, Emmanuel Bourg [EMAIL PROTECTED] wrote:
Russel Winder a écrit :
This command works for me on Ubuntu Hardy with JDK 1.6.0_07-b06 and
Maven 2.0.9. I have noticed that this build has failed for three weeks
now but it seems there is no-one around picking up on it.
I guess there
This one is an incompatible interface change in Expression.java (added
a throws clause to several methods) introduced with
http://svn.apache.org/viewvc/commons/proper/jelly/trunk/src/java/org/apache/commons/jelly/expression/Expression.java?r1=718134r2=718133pathrev=718134
Some other jelly-tags
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-javaflow has an issue affecting its community integration.
This
On 2009-01-12, Ralph Goers ralph.go...@dslextreme.com wrote:
OK. Someone more knowledgeable in Gump is going to have to explain to
me why this failed even though the build succeeded.
I'll be happy to.
I can see that it is looking for commons-vfs-2.0-SNAPSHOT.jar? That
jar is created by
On 2009-01-12, Ralph Goers ralph.go...@dslextreme.com wrote:
I could also use some help understanding why these tests are failing.
I can't duplicate these failures.
The tests only fail if you use Gump-built artifacts (i.e. trunk
instead of the specified versions) for the dependencies.
I
If you look at the bottom of
http://vmgump.apache.org/gump/public/ivy/ivy-tests/index.html you see
links to all the test reports, this is achieved by the junitreport
element in the Gump descriptor.
I have just now added such an element to the descriptor of
commons-configuration-test
Hi all,
to be honest I'm not familiar enough with mvn to really know how to
debug things, but I'll explain how Gump and mvn play together and toss
out some ideas. Maybe at the end of the thread we will know how to
really debug things. If you can come up with a better idea, I'll be
grateful.
I've just removed all dependencies from commons-configuration to show
that the tests pass and plan to add Xerces and Xalan back in to see
whether it really is the XML part that is causing the problems.
Stefan
-
To unsubscribe,
On 2009-01-13, Stefan Bodewig bode...@apache.org wrote:
I've just removed all dependencies from commons-configuration to show
that the tests pass
this part worked, the build passed.
and plan to add Xerces and Xalan back in to see whether it really is
the XML part that is causing
On 2009-01-14, Stefan Bodewig bode...@apache.org wrote:
On 2009-01-13, Stefan Bodewig bode...@apache.org wrote:
The next Gump build (after the currently running one) will use Xerces'
and xml-api's trunk.
The tests still passed. Next up is Xalan.
Stefan
There have been two changes in parallel, vmgump switched to Java6 and
Xalan has been added as a dependency.
Given that the tests passed on gump.zones.ao before I added Xalan (and
this has been running Java6 before), I'd suggest that the
configuration committers experiment with using Xalan 2.7.1
On 2009-01-17, Oliver Heger oliver.he...@oliver-heger.de wrote:
Stefan Bodewig wrote:
There have been two changes in parallel, vmgump switched to Java6 and
Xalan has been added as a dependency.
Given that the tests passed on gump.zones.ao before I added Xalan (and
this has been running
On 2009-01-19, Oliver Heger oliver.he...@oliver-heger.de wrote:
Stefan Bodewig schrieb:
The currently failing build of configuration-test uses the configured
depenencies and downlads them from Maven central except for:
* Xerces
* Xalan
* xml-apis
* xml-resolver
* Ant
* JUnit
Hi all,
I've just merged two changes made to the Ant zip code base -
commons-compress' great-grand-parent - into the sandbox and intend to
keep doing this as we make changes in Ant.
There is another change in Ant that may lead to a tiny performance
improvement by using JDK 1.4 collections
On 2009-02-04, Mark Fortner phidia...@gmail.com wrote:
I'm not a committer to the project, but I've worked on other projects with
svn and JIRA. If you use the Eclipse, there's a plugin called Mylyn that
you can use that makes this process a little easier.
Thanks for the pointer Mark.
I've
On 2009-02-05, Christian Grobmeier grobme...@gmail.com wrote:
* ZipOutputStream contains some proteted static final byte[]
constants
This means any subclass could modify them. Findbugs suggests to
make the package private. Ant couldn't do that because of backwards
incompatibility, but
On 2009-02-07, Dan Fabulich d...@fabulich.com wrote:
Assuming I don't yet have karma to write to the sandbox, may I
politely ask someone to grant it to me?
Should be done now.
Stefan
-
To unsubscribe, e-mail:
Hi,
I've merged ZipEntry into ZipArchiveEntry and ZipOutputStream into
ZipArchiveOutputStream. As a side effect ZipArchiveOutputStream now
supports encoding of file names and the zip file comment (among other
things that it does better than java.util.zip.ZipOutputStream like
providing usable
Hi,
I change ArchiveOutputStream extend FilterOutputStream while I
modified ZipArchiveOutputStream and it seems a very natural thing to
do for all the other streams as well.
All concrete compressor/archiver streams have constructors that take a
different stream as their argument and most of them
401 - 500 of 1182 matches
Mail list logo
