Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

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 in [co

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

On Thu, 29 Feb 2024 at 09:53, Piotr P. Karwasz wrote: > > Hi sebb, > > On Thu, 29 Feb 2024 at 10:25, sebb wrote: > > > but dependency management can be used to > > > prevent version mismatches. > > > > What dependency management is that? Does Maven manage this? > > Seems like users would be force

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

Hi sebb, On Thu, 29 Feb 2024 at 10:25, sebb wrote: > > but dependency management can be used to > > prevent version mismatches. > > What dependency management is that? Does Maven manage this? > Seems like users would be forced to use extra controls to ensure only > comaptible combinations of arti

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

On Thu, 29 Feb 2024 at 00:13, Piotr P. Karwasz wrote: > > Hi sebb, > > On Wed, 28 Feb 2024 at 23:48, sebb wrote: > > > Remark that I am talking about moving whole packages to new artifacts. > > > > Will these packages be renamed? > > > > If not, then I don't see how you can prevent possible class

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

Hi sebb, On Wed, 28 Feb 2024 at 23:48, sebb wrote: > > Remark that I am talking about moving whole packages to new artifacts. > > Will these packages be renamed? > > If not, then I don't see how you can prevent possible class duplication. Do they need to be renamed? This breaks backward compatib

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

On Wed, 28 Feb 2024 at 20:06, Piotr P. Karwasz wrote: > > Hi Romain, > > On Wed, 28 Feb 2024 at 16:30, Romain Manni-Bucau > wrote: > > > > Hmm, splitting will require a package change at least for osgi. > > OSGi should be painless: the common practice is to use > `Import-Package` instead of `Req

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

Hi Romain, On Wed, 28 Feb 2024 at 16:30, Romain Manni-Bucau wrote: > > Hmm, splitting will require a package change at least for osgi. OSGi should be painless: the common practice is to use `Import-Package` instead of `Require-Bundle`, this way it is up to the OSGi environment to figure out that

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

Hmm, splitting will require a package change at least for osgi. Thats said as mentionned here the dependencies are used by laziness but it is trivial to copy the few needed class so no need to break consumers IMHO. Le mer. 28 févr. 2024 à 15:03, Piotr P. Karwasz a écrit : > Hi Elliotte, > > On

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

Hi Elliotte, On Wed, 28 Feb 2024 at 13:44, Elliotte Rusty Harold wrote: > I'm not quite sure what you're proposing. This works if you also > change the package to something like org.apache.commons.compress2. It > does not work without changing the package names. The bottom line is: > > 1. A class

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

> This works if you also change the package to something like org.apache.commons.compress2 Yas, I mean this. Elliotte Rusty Harold 于2024年2月28日周三 20:44写道： > On Tue, Feb 27, 2024 at 1:43 PM Piotr P. Karwasz > wrote: > > > > Hi Elliotte, > > > > On Tue, 27 Feb 2024 at 13:20, Elliotte Rusty Harold

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

Hi Andrew. > Is this the wrong place for such a question? It is the right place. > how I should find an answer For your own usage you can just add such dependency. For a long-time solution, this usually takes months(sometime even years) for community to decide how to do. Of course this sounds quite

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

Hi all, Is this the wrong place for such a question? If so, would someone be so kind as to let me know how I should find an answer / raise this, please? Thanks, Andy On Thu, Feb 22, 2024 at 12:01 PM Andrew Coates wrote: > Hi all, > > I'm seeing a runtime failure using TarArchiveOutputStream w

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

On Tue, Feb 27, 2024 at 1:43 PM Piotr P. Karwasz wrote: > > 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 Compres

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

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. The > > code that depends on: > > > > *

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

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 be loaded eve

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

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:asm, > * org.tukaani:xz. > >

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

Hi Gary, On Thu, 22 Feb 2024 at 17:14, Gary Gregory wrote: > What I've been going in some projects is to never use Maven optional > dependencies and split Maven projects into multi-module ones and never use > optional dependencies when I care about what depends on what. I totally agree. Maven op

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

The OSGi tests we have do pass but they might not be touching all the right places. Gary On Sat, Feb 24, 2024, 6:23 AM Elliotte Rusty Harold wrote: > It looks like this has been partially fixed at head. The Maven > dependency on commons-io is no longer marked as optional. However the > OSGI dep

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

It looks like this has been partially fixed at head. The Maven dependency on commons-io is no longer marked as optional. However the OSGI dependencies are still optional. It's been a few years since I last had to think about OSGI. I'm not sure if this is likely to break anyone or not. On Sat, Feb

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

FYI optional dependency on commons-io is also breaking dependents: https://github.com/apache/maven-assembly-plugin/pull/187#pullrequestreview-1899505395 These dependencies really shouldn't be optional. On Thu, Feb 22, 2024 at 12:08 PM Andrew Coates wrote: > > Hi all, > > I'm seeing a runtime fa

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

On 2024/02/23 12:56:23 Elliotte Rusty Harold wrote: > On Thu, Feb 22, 2024 at 2:07 PM Romain Manni-Bucau > wrote: > > > +1 Elliotte > > ...plus the fact [io] is optional in the pom too which is not correct. > > Possibly commons-io used to be more legitimately optional, but since a > lot of thing

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

On Thu, Feb 22, 2024 at 2:07 PM Romain Manni-Bucau wrote: > +1 Elliotte > ...plus the fact [io] is optional in the pom too which is not correct. Possibly commons-io used to be more legitimately optional, but since a lot of things like CountingOutputStream have now moved into commons-io it really

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

Before splitting maybe review why there are deps, don't think any is really needed and it was mainly pre java 8 time. Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

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 subm

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

> What I've been going in some projects is to never use Maven optional dependencies and split Maven projects into multi-module ones and never use optional dependencies when I care about what depends on what. I love this... just like what done in vfs right?. Gary Gregory 于2024年2月23日周五 00:14写道： >

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

A basic issue is that there is a disconnect between Maven dependency declarations in a POM and running applications outside of Maven aware environment ('mvn' and IDEs). When you write your app, you deliver jars, you start the JVM, and so on, and if you don't follow Maven dependencies you can run in

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

+1 Elliotte ...plus the fact [io] is optional in the pom too which is not correct. Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github | LinkedIn

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

Looks like this was fixed at head a few days ago by using Charsets from commons-io instead of commons-codec, and will be in 1.26.1. That said, I don't really like the fix that was committed. The use of the Charsets class here is trivial and should simply be inlined. It's not sufficient reason to pu

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

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.commons.compress@1.26.0 > > /org.apa

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

Hi Andy, I have the exact same feeling and commons-io is yet another one. I understand the intent to not bring a not used dep when you use only a subset of archives but default experience is not nice. Maybe all these transitive commons deps should be dropped, they dont make much sense anymore IMHO

commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

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.(TarArchive