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 <elh...@ibiblio.org> a écrit : > On Tue, Feb 27, 2024 at 8:27 AM Piotr P. Karwasz > <piotr.karw...@gmail.com> 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. > > > > is already nicely separated in packages. IMHO those packages could be > > moved to separate artifacts **without** requiring a major version bump > > > I wish. It's not that commons-compress is badly factored. It's that > Maven and Java don't really allow for compatible upgrades that split > existing artifacts into new artifacts. This causes big, hard-to-debug > runtime failures. The problem is bad in Java 8 and earlier. It got > much worse in Java 9+ with JPMS. > > The only compatible path that splits artifacts is to rename both the > Maven coordinates AND the packages. Otherwise there will be multiple > copies of the same class in the classpath, and either the wrong one > will be chosen some of the time causing hard to debug runtime failures > or (with JPMS) the JVM will simply refuse to run the program at all. > > What you describe is a good greenfield plan, but it's not a compatible > upgrade, not even with a major version update. > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
