Hi Elliotte, On Wed, 28 Feb 2024 at 13:44, Elliotte Rusty Harold <elh...@ibiblio.org> 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 classpath MUST NOT have the same fully package qualified name in > more than one JAR. This is a hard requirement in Java 9+ with JPMS. > The JVM will not run a program that violates this. It is a very > important requirement in Java 8. > > 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.
Currently Commons Compress 1.26.0 has: * a single `commons-compress` artifact with packages: o.a.c.c.compressors, o.a.c.c.compressors.brotli, etc. What I am proposing is for 1.27.0 to have: * an (almost) empty `commons-compress` artifact that depends on `commons-compress-core`, `commons-compress-brotli`, etc. This artifact should only have a JPMS module descriptor with `requires transitive` directives. * a `commons-compress-brotli` artifact that depends on `org.brotli:dec` and a single package: o.a.c.c.compressors.brotli, * a `commons-compress-core` artifact with packages o.a.c.c.compressors, etc. JPMS does not really care which module has which package. As long as they are disjoint it will be fine. Also, since `commons-compress` will have `requires transitive` directives, libraries compiled against 1.26.0 that use `requires o.a.c.compress;` will still be able to read the `o.a.c.compress.core` module. Piotr --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
