fix: stop publishing a bigtable-beam-import pom with no dependencies

[mutianf]

Problem

bigtable-beam-import 2.20.0 and 2.20.1 were published to Maven Central with zero compile dependencies in their poms.

The module attaches its shaded jar under a classifier (shadedArtifactAttached=true), so the main artifact is the thin, unshaded jar — it needs every one of its compile dependencies declared. maven-shade-plugin strips them from the generated dependency-reduced pom anyway in that configuration (MSHADE-419), which is not fixed in 3.6.0, despite what the comment in the root pom claimed. The bump to 3.6.0 in #4626 flipped the module onto that code path.

Consumers resolving the artifact from a repository get nothing transitively. GoogleCloudPlatform/DataflowTemplates hits this staging the Cloud_Bigtable_to_GCS_SequenceFile template:

ClassNotFoundException: org.apache.hadoop.hbase.io.ImmutableBytesWritable

Every one of these disappeared from the published pom:

bigtable-hbase-beam, beam-sdks-java-core, beam-sdks-java-io-hadoop-format, beam-runners-google-cloud-dataflow-java, hadoop-client-api, hadoop-client-runtime, hbase-shaded-mapreduce, gcs-connector

Why CI didn't catch it

The Maven reactor resolves sibling modules from their source poms and never reads dependency-reduced-pom.xml, so the broken pom is invisible in-repo. There is no in-repo consumer of the published artifact, and neither dependencies.sh nor linkage-monitor inspects the deployed pom.

Changes

1. bigtable-beam-import/pom.xml — set <createDependencyReducedPom>false</createDependencyReducedPom> explicitly, rather than relying on a plugin default whose behavior changed between 3.2.4 and 3.6.0.

2. New verify-published-pom-deps goal in bigtable-build-helper, wired into the module's verify phase. It reads project.getFile() — which shade rewrites to the reduced pom when enabled — so it inspects exactly what would be deployed, and fails the build listing any missing required compile dependency plus a pointer to MSHADE-419. Two integration tests cover the healthy pom and the stripped one.

3. Root pom.xml / renovate.json5 — corrected the comment that asserted 3.6.0 was unaffected, and dropped the renovate rule pinning maven-shade-plugin away from 3.3.0. That rule described the bug incompletely (it isn't specific to 3.3.0), and correcting the range would have banned the 3.6.0 we need for the Java 17 multi-release classes; the explicit flag plus the guard replaces it.

Verification

Check	Result
bigtable-build-helper integration tests	Passed: 8, Failed: 0, Errors: 0, Skipped: 0
mvn -pl bigtable-dataflow-parent/bigtable-beam-import -am verify	BUILD SUCCESS; guard silent; no dependency-reduced-pom.xml generated
Same, with createDependencyReducedPom flipped back to true	BUILD FAILURE; guard reports all 8 deps missing

The negative run reproduces the shipped defect exactly — the same eight artifacts that vanished for DataflowTemplates.

[gemini-code-assist]

Code Review

This pull request introduces a new Maven plugin goal, verify-published-pom-deps, to guard against the maven-shade-plugin stripping required compile dependencies from the published POM (as seen in MSHADE-419). It also adds integration tests to verify this behavior. The review feedback suggests improving the robustness of the new Mojo by adding null and validity checks for the POM file and dependency coordinates, and explicitly specifying UTF-8 encoding when reading the build log in the integration test script.

[gemini-code-assist]

If project.getFile() returns null or a non-existent file (which can happen in certain test environments or synthetic projects), calling readPropagatingDependencies will result in a NullPointerException when opening the FileInputStream. It is safer to check if the file is non-null and is a valid file before proceeding.

    File publishedPom = project.getFile();
    if (publishedPom == null || !publishedPom.isFile()) {
      throw new MojoFailureException("Published POM file is not available or invalid: " + publishedPom);
    }
    Set<String> declared = readPropagatingDependencies(publishedPom);

[mutianf]

Done in 23d3938. Failing loudly beats an NPE here, and more importantly a build that cannot read the pom must not look like it passed the check.

[gemini-code-assist]

If the parsed POM is malformed or missing required fields, dependency.getGroupId() or dependency.getArtifactId() could return null. Adding a null check prevents adding invalid "null:artifactId" or "groupId:null" entries to the declared set.

    for (Dependency dependency : model.getDependencies()) {
      String scope = dependency.getScope();
      // An absent scope means compile.
      if (scope != null && !"compile".equals(scope) && !"runtime".equals(scope)) {
        continue;
      }
      String groupId = dependency.getGroupId();
      String artifactId = dependency.getArtifactId();
      if (groupId != null && artifactId != null) {
        declared.add(resolveGroupId(groupId) + ":" + artifactId);
      }
    }

[mutianf]

Done in 23d3938. A half-declared coordinate cannot satisfy a requirement anyway, so skipping it lets the dependency it was meant to be get reported as missing, which is the outcome we want.

[gemini-code-assist]

Reading the file bytes into a String without specifying a charset uses the platform's default encoding. This can lead to flaky or failing tests on environments (like Windows runners in CI) where the default encoding is not UTF-8. It is safer to explicitly specify StandardCharsets.UTF_8.

String content = new String(Files.readAllBytes(buildLog.toPath()), java.nio.charset.StandardCharsets.UTF_8);

[mutianf]

Skipping this one. Both assertion strings are pure ASCII, which decodes identically under any charset this would realistically run with, so there is no flakiness to fix. The three existing verify.bsh files in this module (verify-shaded-jar-entries-leak, verify-shaded-exclusions-unpromoted, verify-mirror-deps-misaligned) all read the build log the same way, and making only the new one differ costs consistency for no behavior change. Worth doing as a sweep across all four if we ever want it.