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

Gradle plugin in master to depend on the Linkage Checker master

Aberta
  • Algo errado?
#1,651 6 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Estagnada
Stack de tecnologia
java
Domínio
build-system, release

Direção de pesquisa

Comece lendo scripts/prepare_release.sh, build.gradle e os arquivos RELEASING.md vinculados para entender o fluxo atual de versionamento e release. Compare como o plugin Gradle consome o módulo dependencies e defina o comportamento de release descrito na proposta. Considera-se concluído quando master puder usar o LinkageChecker master, enquanto os releases fixarem ambos os componentes na mesma versão e não precisarem mais do sufixo de tag específico do Gradle.

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

Descrição

p3 Tech Debt

As of now, a change to the LinkageChecker class is not immediately used in the Gradle plugin, because the Gradle plugin uses a fixed version of the "com.google.cloud.tools:dependencies" artifact. This disconnection causes pain in:

  • the increased release procedure for the Gradle plugin
  • the late validation of a LinkageChecker's change against the Gradle plugin

Current Release Procedure

Everytime we change LinkageChecker in the dependencies module, we need to do the following

Proposal

The Enforcer Rule in Maven and the Gradle plugin in Gradle

This is an enhancement of current setup of mixing Gradle and Maven and this proposes to enhance the release script "scripts/prepare_release.sh" so that:

  • the Gradle plugin in master branch relies on the LinkageChecker in master. (version latest.integration)
  • When the release script creates a release tag, it sets the dependencies module version in build.gradle to the releasing version. Suppose we use v1.6.0-dependencies.
  • We release the Linkage Checker enforcer rule and the Gradle plugin using the tag v1.6.0-dependencies. No need to wait for Maven Central. As the result, the enforcer rule and the Gradle plugin will have the same version for one release.
    (We no longer use the vX.Y.Z-gradle release tag suffix.)

The Gradle plugin to have java.sourceSet to include ../dependencies/src/main/java

This would have duplicate

Other options considered

Everything in Maven

https://stackoverflow.com/questions/27555560/how-can-i-build-a-gradle-plugin-with-maven . Spring Boot's Gradle plugin was developed in Maven. But now they develop it in Gradle.

The stackoverflow explains https://repo.gradle.org/gradle/libs-releases-local but the latest of https://repo.gradle.org/gradle/libs-releases-local/org/gradle/gradle-core-api/ is 6.1.1. (The latest Gradle version is 6.6). Yet, if some artifacts are missing in Maven Central but available somewhere (as part of Gradle distribution), we can create a Maven local ("libs" directory) repository that holds the artifact in this cloud-opensource-java repository just to build our Gradle plugin. Alternative to the lib directory, we can use the maven-install-plugin to move them to he local repository.

If we don't use Gradle's "com.gradle.plugin-publish" plugin, we'll need to figure out how to upload artifacts to Gradle's plugin repository. (If the Gradle repository changes how it works, we're responsible to adjust it.)

Everything in Gradle

Jib project is all Gradle. They develop Jib Maven plugin in Gradle.

We have settings done in Maven:

  • The Maven invoker plugin for the enforcer rule integration tests.
  • The release script uses mvn versions:set to apply changes to pom.xml at once.

It's feasible but this effort does not sound good just for this purpose to align the Gradle enforcer rule and Maven enfrocer rule.

Linguagem predominante
Java
Estrelas
165
Forks
82
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.