Hi Elliotte, On Tue, 27 Feb 2024 at 13:20, Elliotte Rusty Harold <elh...@ibiblio.org> wrote: > > 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.
Changing Maven coordinates is in my opinion not a good solution in this case. It causes the existence of dependency stacks that feature HTTP client 3.x through 5.x and users are not eager to choose a single version. What about creating: * separate `commons-compress-zstd`, `commons-compress-brotli`, `commons-compress-pack200`, `commons-compress-xz` artifacts with the packages that require external dependencies, * a new `commons-compress-core` (or `-api` and `-impl`) with the rest of the code, * an empty `commons-compress` artifact with a hard dependency on the remaining ones. It just needs a JPMS module descriptor with `requires transitive` directives to the other modules. This way won't have problems when they automatically upgrade `commons-compress`. They'll just end up with many additional dependencies. Piotr --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
