> This works if you also change the package to something like org.apache.commons.compress2 Yas, I mean this.
Elliotte Rusty Harold <elh...@ibiblio.org> 于2024年2月28日周三 20:44写道： > 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 > >
