Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
#2,456 7 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
48/100
Type d'issue
Documentation
Clarté
Plutôt claire
Activité
Calme
Stack technique
java
Domaine
build-system, documentation

Piste de recherche

Commencez par lire le texte actuel de JLBP-6 et le reproducer jarsplit associé. Comparez les indications documentées concernant les classes qui se chevauchent avec le comportement de Maven et Gradle décrit dans l’issue, puis révisez JLBP-6 afin que son périmètre et ses limitations soient exacts. C’est terminé lorsque les indications ne présentent plus le problème spécifique à Maven comme étant universel.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Java
Étoiles
163
Forks
81
Aucune PR mergée en 30 j

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de GoogleCloudPlatform/cloud-opensource-java

Toutes les issues de GoogleCloudPlatform/cloud-opensource-java

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.