On Tue, Feb 27, 2024 at 1:43 PM Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > 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: > > > > 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. >
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. Consequently if a widely used low level library like commons-compress ships two different artifacts (i.e. different groupId:artifactID) that both contain com.example.package.ClassName, it breaks dependents in hard to debug, hard to work around ways. It is a painful and confusing problem that is often hidden behind multiple levels of transitive dependencies. This can happen even in projects that don't directly depend on commons-compress at all. commons-compress is not a green field. It MUST NOT break existing clients by releasing new jars that split packages in existing classpaths. There are only two options: 1. Change Maven coordinates AND package names 2. Keep Maven coordinates AND package names. More detailed discussion of this at: https://jlbp.dev/JLBP-5 https://jlbp.dev/JLBP-6 -- 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
