Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
#2,456 7 comentários 0 reações 0 responsáveis Ver no GitHub

@Suraj8982 já está trabalhando nisso.

Desde 9/11/2025.

Avaliação

Dificuldade
3/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
48/100
Tipo de issue
Documentação
Clareza
Razoavelmente clara
Status de atividade
Pouca atividade
Stack de tecnologia
java

Direção de pesquisa

Comece lendo o texto atual de JLBP-6 e o reproducer de jarsplit vinculado. Compare as orientações documentadas sobre classes sobrepostas com o comportamento do Maven e do Gradle descrito na issue e, em seguida, revise JLBP-6 para que seu escopo e suas limitações estejam corretos. O trabalho estará concluído quando as orientações não apresentarem mais o problema específico do Maven como universal.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Java
Estrelas
165
Forks
82
Métricas de merge de PRs
Nenhum PR com merge em 30d

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de GoogleCloudPlatform/cloud-opensource-java

Todas as issues de GoogleCloudPlatform/cloud-opensource-java

Issues semelhantes

Mais issues de Java

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.