Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
#2,456 7 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
48/100
Tipo de issue
Documentación
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
java
Área
build-system, documentation

Línea de trabajo

Empieza leyendo el texto actual de JLBP-6 y el reproductor de errores de jarsplit enlazado. Compara las indicaciones documentadas sobre clases superpuestas con el comportamiento de Maven y Gradle descrito en el issue y, después, revisa JLBP-6 para que su alcance y sus limitaciones sean precisos. Se considera terminado cuando las indicaciones ya no presentan el problema específico de Maven como universal.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Java
Estrellas
163
Forks
81
Sin PR fusionados en 30 d

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de GoogleCloudPlatform/cloud-opensource-java

Todos los issues de GoogleCloudPlatform/cloud-opensource-java

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.