chore(java-cloud-bom): migrate java-cloud-bom into monorepo by jinseopkim0 · Pull Request #13498 · googleapis/google-cloud-java

jinseopkim0 · 2026-06-16T20:32:01Z

b/477663818

gemini-code-assist

Code Review

This pull request integrates the java-cloud-bom module into the monorepo, introducing BOM configurations, validation tests, a dashboard generator, and release-note utilities. The code review identified several critical issues that need to be addressed: a missing comma in a Python list in updateREADMETable.py causing implicit string concatenation, multiple unclosed file streams in ArtifactMavenData.java and DashboardMain.java leading to resource leaks, a potential deadlock in ReleaseNoteGeneration.java when reading process streams, and missing explicit UTF-8 encoding specifications in both Java and Python file operations.

blakeli0 · 2026-06-22T04:01:24Z

        <artifactId>json</artifactId>
        <version>${json.version}</version>
      </dependency>
+      <dependency>


Why do we need to introduce slf4j to third-party-dependencies?

Thanks for the question. There were errors in full-convergence-check:

Dependency convergence finding for org.slf4j:slf4j-api: - org.slf4j:slf4j-api has conflict: 2.0.13 vs 2.0.16 (from google-cloud-storage)

google-cloud-storage pulled in 2.0.16 transitively, so it was added to third-party-dependencies.

I think we need to get to the bottom of this issue before start managing slf4j in third-party-dependencies.

Which library pulls in 2.0.13? How did google-cloud-storage pull in 2.0.16 transitively?

We tried really hard to make slf4j-api an optional dependency in gax. I don't think we want to start managing its version if there are alternatives.

Thanks for the feedback.

I traced the dependency paths:

slf4j-api:2.0.13 is pulled by org.apache.arrow:arrow-vector:17.0.0 (BigQuery).

slf4j-api:2.0.16 is pulled by com.google.cloud.opentelemetry:exporter-metrics:0.33.0 (Storage).

I pinned slf4j-api:2.0.16 locally inside the POMs of the three BigQuery modules (google-cloud-bigquery, google-cloud-bigquerystorage, and google-cloud-bigquery-jdbc).

(I initially tried upgrading Arrow to 18.0.0 (which uses 2.0.16 natively). However, Arrow 18.0.0 dropped support for Java 8, which broke google-cloud-bigquery-jdbc when running tests on the Java 8 JVM.)

Do you know why this is erroring now but not in previous releases of libraries-bom? Did Bigquery or Storage recently upgraded dependencies?
Also which CI triggers full-convergence-check? I see that shared-dependencies-convergence is actually skipped in this PR.

Thanks for the questions.

Do you know why this is erroring now but not in previous releases of libraries-bom?

This is a version mismatch between Storage and BigQuery dependencies that developed independently on main since the last release. If we had kept the repositories split, this convergence error would still have occurred and blocked the release PR of java-cloud-bom later on. Co-locating them in the monorepo simply surfaces this conflict earlier (at PR time rather than release time).

Did Bigquery or Storage recently upgraded dependencies?

Yes. Storage (via google-cloud-shared-dependencies) upgraded google.cloud.opentelemetry.version, which transitively bumped slf4j-api to 2.0.16. Meanwhile, BigQuery's dependency on arrow-vector:17.0.0 kept it on slf4j-api:2.0.13, creating the mismatch.

Also which CI triggers full-convergence-check?

The GHA units job in java-cloud-bom-ci.yaml. It builds the tests/dependency-convergence module (which has the artifact ID full-convergence-check) as part of the default reactor, running the maven-enforcer-plugin check on every PR.

I see that shared-dependencies-convergence is actually skipped in this PR.

Yes, the shared-dependencies-convergence GHA job is skipped because it is configured to only run on Release Please PRs (release-please--branches--main). However, the actual convergence check (full-convergence-check module) is not skipped—it runs as part of the default reactor during the main units GHA job (mvn install). That is where the failure originally surfaced, and we confirmed it now passes successfully after applying the local pins.

blakeli0 · 2026-06-22T04:12:01Z

We need to generate release note similar to https://github.com/googleapis/java-cloud-bom/releases/tag/v26.83.0. Is there anyway we can test it before merging the PR? If not, can we test it with a pre-release right after merging the PR?

Separately, we need to think about the Github release strategies. I don't think the current release process can create a separate Github release for libraries-bom.

Thanks for the questions and feedback.

We need to generate release note similar to https://github.com/googleapis/java-cloud-bom/releases/tag/v26.83.0. Is there anyway we can test it before merging the PR? If not, can we test it with a pre-release right after merging the PR?

I'll test it with a pre-release right after merging the PR. Created b/526676540 to track this.

Separately, we need to think about the Github release strategies. I don't think the current release process can create a separate Github release for libraries-bom.

Agree. I'm thinking we could have an additional tag (e.g. libraries-bom/v26.84.0), then have GH workflow pick it up to publish the release notes. I've created b/526685922 to track this. I don't think this should be a blocker for this PR. I'll follow-up with a new PR.

blakeli0 · 2026-06-24T17:48:19Z

+    branches:
+    - main
+  pull_request:
+name: java-cloud-bom ci


I don't see this CI and a few others such as bom-content-test being triggered in this PR, is that expected?

Thanks for catching this. I have updated the path filters in the BOM workflows (java-cloud-bom-ci, bom-content-test, validate-bom, and dashboard) so they will now trigger when files under sdk-platform-java/** or google-auth-library-java/** are modified.

blakeli0 · 2026-06-24T17:58:30Z

        <artifactId>json</artifactId>
        <version>${json.version}</version>
      </dependency>
+      <dependency>


I think we need to get to the bottom of this issue before start managing slf4j in third-party-dependencies.

Which library pulls in 2.0.13? How did google-cloud-storage pull in 2.0.16 transitively?

We tried really hard to make slf4j-api an optional dependency in gax. I don't think we want to start managing its version if there are alternatives.

blakeli0 · 2026-06-29T04:57:53Z

      <artifactId>google-cloud-bigquerystorage</artifactId>
      <version>3.30.0-SNAPSHOT</version><!-- {x-version-update:google-cloud-bigquerystorage:current} -->
    </dependency>
+    <dependency>


Can we exclude it without declaring it? Same comment for other bigquery modules

Thanks for the question.

If we exclude slf4j-api from arrow-vector without declaring it in BigQuery, the library compiles and converges, but crashes at runtime with a NoClassDefFoundError when initializing the Arrow allocator:

java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory at org.apache.arrow.memory.BaseAllocator.<clinit>(BaseAllocator.java:49)

Because arrow-vector requires slf4j-api at runtime, we must keep it declared in the BigQuery modules to ensure it is always available on the classpath for end-users who don't otherwise pull it in.

…solution

… BOM downgrade errors

…ness

sonarqubecloud · 2026-06-29T17:36:39Z

Quality Gate passed for 'gapic-generator-java-root'

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

sonarqubecloud · 2026-06-29T17:38:05Z

Quality Gate passed for 'gapic-generator-java-root'

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

gemini-code-assist Bot reviewed Jun 16, 2026

View reviewed changes

jinseopkim0 force-pushed the migrate-java-cloud-bom branch 3 times, most recently from 6f9b129 to 209f419 Compare June 17, 2026 15:36

jinseopkim0 marked this pull request as ready for review June 18, 2026 09:01

jinseopkim0 requested review from a team as code owners June 18, 2026 09:01

jinseopkim0 requested a review from blakeli0 June 18, 2026 09:01

blakeli0 reviewed Jun 22, 2026

View reviewed changes

jinseopkim0 requested a review from blakeli0 June 22, 2026 21:16

blakeli0 reviewed Jun 24, 2026

View reviewed changes

jinseopkim0 requested review from a team as code owners June 25, 2026 18:44

jinseopkim0 force-pushed the migrate-java-cloud-bom branch 3 times, most recently from 2d76bff to d280a93 Compare June 28, 2026 01:56

jinseopkim0 requested a review from a team as a code owner June 28, 2026 18:57

jinseopkim0 force-pushed the migrate-java-cloud-bom branch from 0f05a1a to 7560c18 Compare June 28, 2026 23:07

jinseopkim0 requested a review from blakeli0 June 29, 2026 00:14

blakeli0 reviewed Jun 29, 2026

View reviewed changes

Comment thread .github/CODEOWNERS Outdated

blakeli0 reviewed Jun 29, 2026

View reviewed changes

Comment thread generation/apply_versions.sh Outdated

blakeli0 reviewed Jun 29, 2026

View reviewed changes

Comment thread java-spanner-jdbc/documentation/connection_properties.md

chore(java-cloud-bom): migrate java-cloud-bom into monorepo

d50467f

jinseopkim0 force-pushed the migrate-java-cloud-bom branch from 7560c18 to d50467f Compare June 29, 2026 14:04

jinseopkim0 added 4 commits June 29, 2026 10:04

Merge branch 'main' into migrate-java-cloud-bom

10b72e2

chore: explicitly build java-core in pre-install to fix dependency re…

703efae

…solution

chore: align third-party dependencies in sdk-platform-java to prevent…

4d39a6d

… BOM downgrade errors

test: increase sleep time in ConnectionWorkerPoolTest to reduce flaki…

3a24984

…ness

jinseopkim0 added the kokoro:force-run Add this label to force Kokoro to re-run the tests. label Jun 29, 2026

jinseopkim0 added the kokoro:run Add this label to force Kokoro to re-run the tests. label Jun 29, 2026

yoshi-kokoro removed kokoro:run Add this label to force Kokoro to re-run the tests. kokoro:force-run Add this label to force Kokoro to re-run the tests. labels Jun 29, 2026

Merge branch 'main' into migrate-java-cloud-bom

dfd6bf5

jinseopkim0 requested a review from blakeli0 June 29, 2026 18:30

Uh oh!

Conversation

jinseopkim0 commented Jun 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jinseopkim0 Jun 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jinseopkim0 Jun 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

blakeli0 Jun 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

sonarqubecloud Bot commented Jun 29, 2026

Quality Gate passed for 'gapic-generator-java-root'

Uh oh!

sonarqubecloud Bot commented Jun 29, 2026

Quality Gate passed for 'gapic-generator-java-root'

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

jinseopkim0 commented Jun 16, 2026 •

edited

Loading

jinseopkim0 Jun 25, 2026 •

edited

Loading

jinseopkim0 Jun 22, 2026 •

edited

Loading

blakeli0 Jun 29, 2026 •

edited

Loading