This vote thread passes with the following +1 binding votes:
- Gary Gregory (ggregory)
- Rob Tompkins (chtompki)
- Henri Biestro (henrib)
Gary
On Thu, May 23, 2024 at 9:26 AM Henri Biestro wrote:
>
> [ +1 ]
>
> Site looks good, javadoc looks good, reports Ok (nit jacoco missing).
>
> Tested
[ +1 ]
Site looks good, javadoc looks good, reports Ok (nit jacoco missing).
Tested using:
mvn clean install site
On:
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/hbiestro/Java/apache-maven-3.8.6
Java version: 17.0.8, vendor: Oracle Corporation, runtime:
+1
> On May 18, 2024, at 12:56 PM, Gary Gregory wrote:
>
> We have fixed a few bugs since Apache Commons Compress 1.26.1 was
> released, so I would like to release Apache Commons Compress 1.26.2.
>
> Apache Commons Compress 1.26.2 RC1 is available for review here:
>ht
My +1
Gary
On Sat, May 18, 2024, 12:56 PM Gary Gregory wrote:
> We have fixed a few bugs since Apache Commons Compress 1.26.1 was
> released, so I would like to release Apache Commons Compress 1.26.2.
>
> Apache Commons Compress 1.26.2 RC1 is available for review here:
We have fixed a few bugs since Apache Commons Compress 1.26.1 was
released, so I would like to release Apache Commons Compress 1.26.2.
Apache Commons Compress 1.26.2 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/compress/1.26.2-RC1
(svn revision 69274
If you read the CVE, especially "Known affected configuration" you'll see
that the issue was fixed in 1.26.0.
Gary
On Wed, Mar 13, 2024, 9:22 AM Puneet Samaiya
wrote:
> Hello There,
>
> We've identified a vulnerability in our code related to
> commons-compress-1.21.jar (e
below makes the test pass. Whether this should
> be default for the one-arg constructor is a matter for discussion.
> Peter
> diff --git
> a/src/test/java/org/apache/commons/compress/compressors/bzip2/BZip2Compress651Test.java
> b/src/test/java/org/apache/commons/compress/compres
Thanks for the reminder, Peter. That rings a bell... vaguely.
Can this test pass by configuring the input stream differently?
Gary
On Sat, Mar 9, 2024 at 1:21 PM Peter Hull wrote:
>
> On Sat, 9 Mar 2024 at 14:33, Gary Gregory wrote:
> >
> > If you want to help in Commons COM
ussion.
Peter
diff --git
a/src/test/java/org/apache/commons/compress/compressors/bzip2/BZip2Compress651Test.java
b/src/test/java/org/apache/commons/compress/compressors/bzip2/BZip2Compress651Test.java
index d5c7e17c9..079a90c37 100644
---
a/src/test/java/org/apache/commons/compress/compressors
On Sat, 9 Mar 2024 at 14:33, Gary Gregory wrote:
>
> If you want to help in Commons COMPRESS-land, please see
> https://issues.apache.org/jira/browse/COMPRESS-651
I swear I looked into this a while ago, and the issue was pbzip2 works
by compressing the source in chunks, in parallel, the
If you want to help in Commons COMPRESS-land, please see
https://issues.apache.org/jira/browse/COMPRESS-651
TY,
Gary
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h
The Apache Commons team is pleased to announce Apache Commons Compress
Version 1.26.1.
Apache Commons Compress defines an API for working with compression and
archive formats. These include bzip2, gzip, pack200, LZMA, XZ,
Snappy, traditional Unix Compress, DEFLATE, DEFLATE64, LZ4, Brotli
egory
> > wrote:
> > >
> > > We have fixed a few bugs and added some enhancements since Apache
> > > Commons Compress 1.26.0 was released, so I would like to release
> > > Apache Commons Compress 1.26.1.
> > >
> > > Apache Commons Compress
; On Tue, Mar 5, 2024 at 5:40 PM Gary Gregory
> > wrote:
> > >
> > > We have fixed a few bugs and added some enhancements since Apache
> > > Commons Compress 1.26.0 was released, so I would like to release
> > > Apache Commons Compress 1.26.1.
> > >
> &g
-generic", arch: "amd64", family:
"unix"
On Wed, 6 Mar 2024 at 17:25, Gary Gregory wrote:
> My +1
>
> Gary
>
> On Tue, Mar 5, 2024 at 5:40 PM Gary Gregory
> wrote:
> >
> > We have fixed a few bugs and added some enhancements since Apache
> >
My +1
Gary
On Tue, Mar 5, 2024 at 5:40 PM Gary Gregory wrote:
>
> We have fixed a few bugs and added some enhancements since Apache
> Commons Compress 1.26.0 was released, so I would like to release
> Apache Commons Compress 1.26.1.
>
> Apache Commons Compress 1.26.1 RC1 is av
+1 (non-binding)
I only checked it out and tested it locally with our application.
On Tue, Mar 5, 2024 at 5:43 PM Gary Gregory wrote:
> We have fixed a few bugs and added some enhancements since Apache
> Commons Compress 1.26.0 was released, so I would like to release
> Apache Commons
+1 tested builds on java 8 -21, site - reports all look good, RELEASE-NOTES.txt
good, signatures good.
> On Mar 5, 2024, at 5:40 PM, Gary Gregory wrote:
>
> We have fixed a few bugs and added some enhancements since Apache
> Commons Compress 1.26.0 was released, so I would lik
this version of Commons
Compress. Confirmed that the changes to TarArchiveOutputStream for COMPRESS-659
work as expected, without requiring the optional commons-codec dependency.
Thanks Gary!
Regards,
David Handermann
Apache NiFi PMC Member
We have fixed a few bugs and added some enhancements since Apache
Commons Compress 1.26.0 was released, so I would like to release
Apache Commons Compress 1.26.1.
Apache Commons Compress 1.26.1 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1
Added a comment to explain splitting will have more impacts and BOM does
not even solve it inline.
But stepping back the only issue compress has today is [io] and a bit
[codec].
Most of the needed dependencies can be restore in [compress] - keep in mind
before the dependency code was hosted
en manage this?
> > Seems like users would be forced to use extra controls to ensure only
> > comaptible combinations of artifacts were used.
>
> Maven users would be forced to add a new `commons-compress-bom`
> artifact (in my PR) to their dependency management. As far as I know
> o
comaptible combinations of artifacts were used.
Maven users would be forced to add a new `commons-compress-bom`
artifact (in my PR) to their dependency management. As far as I know
other build systems (Gradle, Coursier, probably Apache Ivy) resolve
version conflicts with a "highest version
then I don't see how you can prevent possible class duplication.
>
> Do they need to be renamed? This breaks backward compatibility.
Yes, to avoid class chaos.
> A user could have duplicated classes if he has an old
> `commons-compress` 1.26.0 together with a newer
> `commons-compres
is breaks backward compatibility.
A user could have duplicated classes if he has an old
`commons-compress` 1.26.0 together with a newer
`commons-compress-core`, but dependency management can be used to
prevent version mismatches.
Since an example is better than a thousand words I submitted a PoC on
ho
to use
> `Import-Package` instead of `Require-Bundle`, this way it is up to the
> OSGi environment to figure out that a certain package is in
> `commons-compress-core` instead of `commons-compress`.
>
> Remark that I am talking about moving whole packages to new artifacts.
Will these packag
re out that a certain package is in
`commons-compress-core` instead of `commons-compress`.
Remark that I am talking about moving whole packages to new artifacts.
If we were to split a package in two parts, I agree with the previous
posts that a new major version, Maven coordinates and package
; >
> > 2. Maven and Gradle cannot resolve dependency conflicts between jars
> > with different groupID:artifactID. They both treat them as fully
> > independent artifacts, even if they're not, and will add both to a
> > classpath, thereby violating rule #1.
>
>
e dependency conflicts between jars
> with different groupID:artifactID. They both treat them as fully
> independent artifacts, even if they're not, and will add both to a
> classpath, thereby violating rule #1.
Currently Commons Compress 1.26.0 has:
* a single `commons-compress` arti
4 at 13:20, Elliotte Rusty Harold
> wrote:
> > >
> > > On Tue, Feb 27, 2024 at 8:27 AM Piotr P. Karwasz
> > > wrote:
> > > e will not be loaded even if it is available.
> > > >
> > > > Fortunately Commons Compress is well-e
Andy
>
> On Thu, Feb 22, 2024 at 12:01 PM Andrew Coates
> wrote:
>
> > Hi all,
> >
> > I'm seeing a runtime failure using TarArchiveOutputStream when updating
> to
> > commons-compress 1.26.0.
> >
> > java.lang.NoClassDefFoundError: or
putStream when updating to
> commons-compress 1.26.0.
>
> java.lang.NoClassDefFoundError: org/apache/commons/codec/Charsets
> at org.apache.commons.compress@1.26.0
> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArch
ilable.
> > >
> > > Fortunately Commons Compress is well-engineered and easy to split. The
> > > code that depends on:
> > >
> What about creating:
> * separate `commons-compress-zstd`, `commons-compress-brotli`,
> `commons-compress-pack200`, `commons-compr
Hi Elliotte,
On Tue, 27 Feb 2024 at 13:20, Elliotte Rusty Harold wrote:
>
> On Tue, Feb 27, 2024 at 8:27 AM Piotr P. Karwasz
> wrote:
> e will not be loaded even if it is available.
> >
> > Fortunately Commons Compress is well-engineered and easy to split. T
Hmm maven does but let's step back, no dependency is useful for compress so
maybe we drop them and stop the thread? Any real point discussing it?
Le mar. 27 févr. 2024 à 13:20, Elliotte Rusty Harold a
écrit :
> On Tue, Feb 27, 2024 at 8:27 AM Piotr P. Karwasz
> wrote:
> e will not
On Tue, Feb 27, 2024 at 8:27 AM Piotr P. Karwasz
wrote:
e will not be loaded even if it is available.
>
> Fortunately Commons Compress is well-engineered and easy to split. The
> code that depends on:
>
> * com.github.luben:zstd-jni,
> * org.brotli:dec,
> * org.ow2.asm:as
directive becomes
problematic: a JPMS Commons Compress user not only needs to add
`commons-codec` to its Maven dependencies, but also needs to add
`org.apache.commons.codec` to its required modules. If he fails to do
so the module will not be loaded even if it is available.
Fortunately Commons Compres
; > wrote:
> > >
> > > Hi all,
> > >
> > > I'm seeing a runtime failure using TarArchiveOutputStream when
> updating to
> > > commons-compress 1.26.0.
> > >
> > > java.lang.NoClassDefFoundError: org/apache/commons/codec/Charsets
> > &
u, Feb 22, 2024 at 12:08 PM Andrew Coates
> wrote:
> >
> > Hi all,
> >
> > I'm seeing a runtime failure using TarArchiveOutputStream when updating to
> > commons-compress 1.26.0.
> >
> > java.lang.NoClassDefFoundError: org/apache/com
ng a runtime failure using TarArchiveOutputStream when updating to
> commons-compress 1.26.0.
>
> java.lang.NoClassDefFoundError: org/apache/commons/codec/Charsets
> at org.apache.commons.compress@1.26.0
> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarA
optional, but since a
> lot of things like CountingOutputStream have now moved into commons-io
> it really isn't. Is there anywhere explicit documentation of what
> dependencies commons-compress uses?
Yes, the web site. Each Commons Components web site should have a "Dependency
Manage
ons-io
it really isn't. Is there anywhere explicit documentation of what
dependencies commons-compress uses?
It is really helpful for clients when libraries make a strong effort
to avoid unnecessary dependencies. I can sort of see that a library
like compress might depend on lang3 and io, but it would be
t; | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le jeu. 22 févr. 2024 à 17:29, Xeno Amess a écrit :
> Another reason for suggesting common-compres
Another reason for suggesting common-compress split to several sub-modules:
I see no application, nor lib, nor software that use common-compress and
use all of the algorithms supported by common-compress...
Usually we just use one or two algorithms we actually need...
so splitting into several
2024, 4:08 AM Andrew Coates
> wrote:
>
> > Hi all,
> >
> > I'm seeing a runtime failure using TarArchiveOutputStream when updating
> to
> > commons-compress 1.26.0.
> >
> > java.lang.NoClassDefFoundError: org/apache/commons/codec/Charsets
> >
ntime failure using TarArchiveOutputStream when updating to
> commons-compress 1.26.0.
>
> java.lang.NoClassDefFoundError: org/apache/commons/codec/Charsets
> at org.apache.commons.compress@1.26.0
>
> /org.apache.commons.compress.archivers.tar.TarArchiveOutputSt
commons-codec or commons-io.
>
> On Thu, Feb 22, 2024 at 7:08 AM Andrew Coates
> wrote:
> >
> > Hi all,
> >
> > I'm seeing a runtime failure using TarArchiveOutputStream when updating
> to
> > commons-compress 1.26.0.
> >
> > java.la
to pull in an external Charsets class from either
commons-codec or commons-io.
On Thu, Feb 22, 2024 at 7:08 AM Andrew Coates wrote:
>
> Hi all,
>
> I'm seeing a runtime failure using TarArchiveOutputStream when updating to
> commons-compress 1.26.0.
>
> java.lang.NoClassDefF
On Thu, 22 Feb 2024 at 12:08, Andrew Coates
wrote:
> Hi all,
>
> I'm seeing a runtime failure using TarArchiveOutputStream when updating to
> commons-compress 1.26.0.
>
> java.lang.NoClassDefFoundError: org/apache/commons/codec/Charsets
> at org.apache.co
ps://www.packtpub.com/application-development/java-ee-8-high-performance>
Le jeu. 22 févr. 2024 à 13:08, Andrew Coates a
écrit :
> Hi all,
>
> I'm seeing a runtime failure using TarArchiveOutputStream when updating to
> commons-compress 1.26.0.
>
> java.lang.N
Hi all,
I'm seeing a runtime failure using TarArchiveOutputStream when updating to
commons-compress 1.26.0.
java.lang.NoClassDefFoundError: org/apache/commons/codec/Charsets
at org.apache.commons.compress@1.26.0
/org.apache.commons.compress.archivers.tar.TarArchiveOutputStream
n message - and the message has changed.
>
> I have updated the POI code to check for the new message as well as the
> old message.
>
> I think this should be enough. Apologies for the noise.
>
>
>
> On 2024/02/20 15:59:12 PJ Fanning wrote:
> > Hi everyone,
> >
> > I
as the old
message.
I think this should be enough. Apologies for the noise.
On 2024/02/20 15:59:12 PJ Fanning wrote:
> Hi everyone,
>
> I upgraded Apache POI to use the latest commons-compress 1.26.0 release. POI
> processes Microsoft format files like xlsx and docs files - t
Hi everyone,
I upgraded Apache POI to use the latest commons-compress 1.26.0 release. POI
processes Microsoft format files like xlsx and docs files - these formats are
basically zip files with XML and other files contained within.
The issue seems to be that commons-compress 1.26.0 requires
The Apache Commons team is pleased to announce Apache Compress 1.26.0.
Apache Commons Compress defines an API for working with compression
and archive formats. These include bzip2, gzip, pack200, LZMA, XZ,
Snappy, traditional Unix Compress, DEFLATE, DEFLATE64, LZ4, Brotli,
Zstandard and ar, cpio
were cast:
+1 Arnout Engelen
-10 Elliotte Rusty Harold
Thank you all for reviewing,
Gary
On Sun, Feb 18, 2024 at 11:37 PM Rob Tompkins wrote:
>
> +1 - all looks good
>
> > On Feb 17, 2024, at 7:14 PM, Gary Gregory wrote:
> >
> > [VOTE] Release Apache Commons C
+1 - all looks good
> On Feb 17, 2024, at 7:14 PM, Gary Gregory wrote:
>
> [VOTE] Release Apache Commons Compress 1.26.0 based on RC1
>
> We have fixed a few bugs and added some enhancements since Apache
> Commons Compress 1.25.0 was released, so I would like to releas
to contact me privately.
>
> >
> > Specific issues:
> >
> > https://github.com/apache/commons-compress/commit/9f2f97925fdb52b5a3a32da6337ea1f113a3be82
> > is wonky and rates a -1 from me. An encoding error is not necessarily
> > an I/O error, and It's arguably
On Sun, Feb 18, 2024 at 9:51 AM Gary Gregory wrote:
> > There seem to have been a lot of needless deprecations of constructors
> > and replacement with builder patterns.
>
> The use of the builder pattern avoids constructor inflation. For
> example, we had fourteen (14) constructors for ZipFile,
ommitters.
- Just so you know, for this release, there are other moving parts,
please feel free to contact me privately.
>
> Specific issues:
>
> https://github.com/apache/commons-compress/commit/9f2f97925fdb52b5a3a32da6337ea1f113a3be82
> is wonky and rates a -1 from me. An encoding
Meta issue: the use of direct git commits without PRs or code review
makes releases harder to review.
Specific issues:
https://github.com/apache/commons-compress/commit/9f2f97925fdb52b5a3a32da6337ea1f113a3be82
is wonky and rates a -1 from me. An encoding error is not necessarily
an I/O error
My +1
Gary
On Sun, Feb 18, 2024 at 12:14 AM Gary Gregory wrote:
>
> [VOTE] Release Apache Commons Compress 1.26.0 based on RC1
>
> We have fixed a few bugs and added some enhancements since Apache
> Commons Compress 1.25.0 was released, so I would like to release
> Apach
"5.15.0-94-generic", arch: "amd64", family:
"unix"
Site reports look OK.
Thanks!
On Sun, 18 Feb 2024 at 01:15, Gary Gregory wrote:
> [VOTE] Release Apache Commons Compress 1.26.0 based on RC1
>
> We have fixed a few bugs and added some enhancements since
* checked the zip and tar.gz match the sha512sum above
* checked the zip and tar.gz match the code at the tag
* checked they were signed with 2DB4F1EF0FA761ECC4EA935C86FDC7E2A11262CB
* built with 'mvn clean install'
* checked the built commons-compress-1.26.0.pom was bit-by-bit identical
[VOTE] Release Apache Commons Compress 1.26.0 based on RC1
We have fixed a few bugs and added some enhancements since Apache
Commons Compress 1.25.0 was released, so I would like to release
Apache Commons Compress 1.26.0.
Apache Commons Compress 1.26.0 RC1 is available for review here:
https
I can't add to the JIRA bug but I had a quick play on WSL (debian),
Java 21, compress 1.25.0 and found:
Using dd if=/dev/random I could create a big file, compress it with
bzip2 and then decompress it with BZip2CompressorInputStream , no
problems
Same file compressed with pbzip2 was truncated
Hi All,
If anyone is looking for an issue to investigate:
[COMPRESS-651] Decompress BZIP2 File Max Output is 90 chars
https://issues.apache.org/jira/browse/COMPRESS-651
Gary
-
To unsubscribe, e-mail: dev-unsubscr
ase let me know if there is additional work that needs to be
> done. I would really like to get this issue fixed for the next release.
>
> https://issues.apache.org/jira/browse/COMPRESS-655
> https://github.com/apache/commons-compress/pull/457
>
> Thanks,
> Chad
>
.
https://issues.apache.org/jira/browse/COMPRESS-655
https://github.com/apache/commons-compress/pull/457
Thanks,
Chad
;hard" to saying we'll provide allow and/or deny lists in the future.
For memory and CPU consumption issues, we want to avoid zip-bomb issues, and
that's where code inspections and fuzzing will help and has already helped.
Commons Imaging and Compress are two obvious targets here. It's going to
On Thu, Dec 14, 2023 at 9:31 AM Arnout Engelen wrote:
>
> Examples of what I referred to as arbitrary code execution would be
> unbounded deserialization of untrusted data (via techniques like those
> described in the motivation for
>
On Thu, Dec 14, 2023 at 8:31 AM Arnout Engelen wrote:
> On Thu, Dec 14, 2023 at 2:00 PM Elliotte Rusty Harold
> wrote:
>
> > On Thu, Dec 14, 2023 at 6:09 AM Arnout Engelen
> wrote:
> > > * I'd say parsing/decompression/decoding should never allow malicious
> > input
> > > to trigger arbitrary
On Thu, Dec 14, 2023 at 2:00 PM Elliotte Rusty Harold
wrote:
> On Thu, Dec 14, 2023 at 6:09 AM Arnout Engelen wrote:
> > * I'd say parsing/decompression/decoding should never allow malicious
> input
> > to trigger arbitrary code execution(?)
>
> Do any of these products include native
On Thu, Dec 14, 2023 at 6:09 AM Arnout Engelen wrote:
>
> Hello Commons developers,
>
> I'd like to discuss what our security ambitions are for components like
> Commons Imaging, Compress, Codec and IO:
>
> Generally for Commons, we say that unless otherwise specified i
Hello.
Le jeu. 14 déc. 2023 à 12:10, Arnout Engelen a écrit :
>
> Hello Commons developers,
>
> I'd like to discuss what our security ambitions are for components like
> Commons Imaging, Compress, Codec and IO:
>
> Generally for Commons, we say that unless otherwi
Hello Commons developers,
I'd like to discuss what our security ambitions are for components like
Commons Imaging, Compress, Codec and IO:
Generally for Commons, we say that unless otherwise specified it is up to
the user of the library to make sure any input is either trusted or
correctly
Hi All,
I'd like community feedback on whether it is OK to merge
https://github.com/apache/commons-compress/pull/378
TY!
Gary
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h
The Apache Commons team announces Commons Compress version 1.25.0
Apache Commons Compress defines an API for working with compression
and archive formats. These include bzip2, gzip, pack200, LZMA, XZ,
Snappy, traditional Unix Compress, DEFLATE, EFLATE64, LZ4, Brotli,
Zstandard and ar, cpio, jar
it :-)
> >
> > > On Nov 12, 2023, at 5:47 PM, Gary Gregory wrote:
> > >
> > > We have fixed a few bugs and added some enhancements since Apache
> > > Commons Compress 1.24.0 was released, so I would like to release
> > > Apache Commons Compress 1.25.0
urs the well prepared …. generally
> needing it :-)
>
> > On Nov 12, 2023, at 5:47 PM, Gary Gregory wrote:
> >
> > We have fixed a few bugs and added some enhancements since Apache
> > Commons Compress 1.24.0 was released, so I would like to release
> > Apache Common
ote:
>
> We have fixed a few bugs and added some enhancements since Apache
> Commons Compress 1.24.0 was released, so I would like to release
> Apache Commons Compress 1.25.0.
>
> Apache Commons Compress 1.25.0 RC1 is available for review here:
>https://dist.apache.org/repos/d
> [X] +1 Release these artifacts
Signatures ok, build and tests run fine, site and reports look good.
Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /Users/thomas/Dev/apache-maven-3.8.4
Java version: 17.0.8, vendor: Oracle Corporation, runtime:
gs and added some enhancements since Apache
> Commons Compress 1.24.0 was released, so I would like to release
> Apache Commons Compress 1.25.0.
>
> Apache Commons Compress 1.25.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/compress/1.25.0-R
We have fixed a few bugs and added some enhancements since Apache
Commons Compress 1.24.0 was released, so I would like to release
Apache Commons Compress 1.25.0.
Apache Commons Compress 1.25.0 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/compress/1.25.0
Hello,
I've created JIRA COMPRESS-650 for a bug I found while doing lz4
compression. I also created a pull request with a fix for this bug. Please
let me know what you think.
https://github.com/apache/commons-compress/pull/436
Thanks,
Chad Preisler
Severity: moderate
Affected versions:
- Apache Commons Compress 1.22 before 1.24.0
Description:
Improper Input Validation, Uncontrolled Resource Consumption vulnerability in
Apache Commons Compress in TAR parsing.This issue affects Apache Commons
Compress: from 1.22 before 1.24.0.
Users
The Apache Commons Team announces Apache Commons Compress 1.24.0.
Apache Commons Compress defines an API for working with compression
and archive formats. These include: bzip2, gzip, pack200, lzma, xz,
Snappy, traditional Unix Compress, DEFLATE, DEFLATE64, LZ4, Brotli,
Zstandard and ar, cpio, jar
ava 11, 17,
> > Signatures all check out,
> > Reports all look good.
> >
> > Cheers, and thanks a ton for all the good work!
> > -Rob
> >
> > > On Sep 4, 2023, at 9:22 AM,Gary Gregory wrote:
> > >
> > > We have fixed a few bugs
rote:
> >
> > We have fixed a few bugs and added one enhancement since Apache
> > Commons Compress 1.23.0 was released, so I would like to release
> > Apache Commons Compress 1.24.0.
> >
> > Apache Commons Compress 1.24.0 RC1 is available for review here:
> >
+1
Build works on java 11, 17,
Signatures all check out,
Reports all look good.
Cheers, and thanks a ton for all the good work!
-Rob
> On Sep 4, 2023, at 9:22 AM,Gary Gregory wrote:
>
> We have fixed a few bugs and added one enhancement since Apache
> Commons Compress 1.23.0 was re
My [+1] vote.
After a long trial & error process, got it to compile and test thanks Gary for
the patience and help);
Tidbits on the release, a few warnings could be quiesced and the release notes
seem short.
Tested using:
mvn -s "$HOME/.m2/commons-settings.xml" -V clean package site
with:
:18 AM Gary Gregory wrote:
>
> Hi Henri,
>
> What command are you running exactly? I'd like to reproduce your issue
> locally.
>
> This is odd since all builds are green on Java 8, 11, and 17 on macOS,
> Windows, and Linux: https://github.com/apache/commons-compress/actions
Hi Henri,
What command are you running exactly? I'd like to reproduce your issue locally.
This is odd since all builds are green on Java 8, 11, and 17 on macOS,
Windows, and Linux: https://github.com/apache/commons-compress/actions
Gary
On Wed, Sep 6, 2023 at 5:54 AM Henri Biestro wrote
] OsgiITest.properlyDetectsRunningInsideOsgiEnv » Unable to lock
bundle cache: java.nio.channels.OverlappingFileLockException
Tried playing with versions of plugin to no avail...
Also noticed a few varargs warnings in tests source. (like
[WARNING]
/Users/hbiestro/Java/apache-commons/compress/commons-compress-1.24.0-RC1/src/test/java/org
We have fixed a few bugs and added one enhancement since Apache
Commons Compress 1.23.0 was released, so I would like to release
Apache Commons Compress 1.24.0.
Apache Commons Compress 1.24.0 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/compress/1.24.0-RC1
The Apache Commons Compress team is happy to announce the release of
version 1.23.0.
Apache Commons Compress defines an API for working with compression
and archive formats.
These include: bzip2, gzip, pack200, lzma, xz, Snappy, traditional
Unix Compress, DEFLATE, DEFLATE64, LZ4, Brotli
uite a few bugs and added some significant enhancements
> > since Apache Commons Compress 1.22 was released, so I would like to
> > release Apache Commons Compress 1.23.0.
> >
> > Apache Commons Compress 1.23.0 RC1 is available for review here:
> > https://dist.ap
My +1
Gary
On Sat, Mar 18, 2023 at 2:05 PM Gary Gregory wrote:
>
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Compress 1.22 was released, so I would like to
> release Apache Commons Compress 1.23.0.
>
> Apache Commons C
have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Compress 1.22 was released, so I would like to
> release Apache Commons Compress 1.23.0.
>
> Apache Commons Compress 1.23.0 RC1 is available for review here:
> https://dist.apache.org/repos/
+1
Build from tag using:
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/henri/Java/apache-maven-3.8.6
Java version: 1.8.0_362, vendor: Azul Systems, Inc., runtime:
/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre
Default locale: en_US, platform
1 - 100 of 2962 matches
Mail list logo
