JLBP-6 is misleading regarding "don’t publish the same classes under multiple Maven IDs"

[vlsi]

The current text is

Whether or not you make breaking changes, don’t publish the same classes under multiple Maven IDs; this creates a situation where artifacts have “overlapping classes.” Another best practice, JLBP-5, covers how consumers need to handle such problematic scenarios — don’t create new cases!

However, in practice this is a Maven-only flaw.

Gradle can handle diamon dependency resolution automatically, and Gradle does enable publishers to evolve their libraries with backward compatibility in mind.

For example:

• commons-compress-1.0.jar: a single jar with all the compressors (gz, tar, zip)
• commons-compress-1.0.jar: no classes, just a pom artifact for backward compatibility. It would depend on all the other commons-compress-*-1.1.jar artifacts
• commons-compress-base-1.1.jar: base interfaces, no compressor code
• commons-compress-tar-1.1.jar: only tar-related classes
• commons-compress-gz-1.1.jar: only gz-related classes

Gradle enables publisher to declare platform constraint (see https://blog.gradle.org/alignment-with-gradle-module-metadata), so the resolver would automatically resolve the diamond.

With Gradle platform in mind, commons-compress-base:1.1 could add platform constraint on commons-compress:1.1.
It will let Gradle know that if it sees commons-compress on the classpath, it should bump it to at least 1.1.

That fixes diamond dependency.

I've published a reproducer project: https://github.com/vlsi/jarsplit
It works fine with Gradle and it fails with Maven, so it highlights that the bug is Maven tool-related only.

[Suraj8982]

Hi @vlsi ,
I’d like to take this issue. From the description and the reproducer, it seems the overlapping classes problem is specific to Maven, while Gradle’s module metadata resolves it via platform constraints. I’ll review JLBP-6 and draft a clarification to distinguish Maven-specific limitations from general best practices. Kindly, assign this issue to me.