Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#2,456 7 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
48/100
Issue-Typ
Dokumentation
Klarheit
Größtenteils klar
Aktivitätsstatus
Ruhig
Tech-Stack
java
Bereich
build-system, documentation

Rechercherichtung

Lies zunächst den aktuellen JLBP-6-Text und den verlinkten jarsplit-Reproducer. Vergleiche die dokumentierte Anleitung zu überlappenden Klassen mit dem im Issue beschriebenen Verhalten von Maven und Gradle, und überarbeite JLBP-6, sodass Umfang und Einschränkungen korrekt sind. Fertig ist die Aufgabe, wenn die Anleitung das Maven-spezifische Problem nicht mehr als universell darstellt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Java
Sterne
163
Forks
81
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus GoogleCloudPlatform/cloud-opensource-java

Alle Issues in GoogleCloudPlatform/cloud-opensource-java

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.