refactor(deps): declare Guava only in consuming modules - #7867

Review: #7867 refactor(deps): declare Guava only in consuming modules

Reviewed the dependency hygiene change across the multi-module build.

What's good

• Guava is removed from the root <dependencies> and declared explicitly in the ~40 consuming modules that actually use it (some as test-scoped). This shrinks the dependency surface for modules that don't need Guava and makes Guava usage auditable per module.
• The change is mechanical and the module list is comprehensive; the build compiled for the touched modules.

Non-blocking suggestions

• Verify the distribution/assembly (shenyu-dist, shade/assembly plugins) still bundles Guava wherever it is needed at runtime, since it is no longer inherited transitively from the root.
• The latest pr_build reports a test failure in shenyu-plugin-tracing, but this PR does not modify that module, and the failure is a surefire test failure (not a Guava compile error), so it looks like a pre-existing flaky test rather than a regression from this refactor. Recommend a re-run of pr_build before merge to confirm tracing is green.

CI note

The other red jobs (build at ~3s, integrated-test matrix, e2e-case) are infra/network flakiness unrelated to a POM-only change. The core compile + unit tests for the touched modules passed.

Verdict

APPROVE — solid dependency cleanup; please re-run CI to confirm the unrelated tracing flake is green before merging.

Re-review: Approved

Re-approving following commit ae67c7786c (test(tracing): await span export in real HTTP continuity checks).

Verification:

• The asynchronous span export in TraceContinuityTest#onlyFinishedSpan is now guarded by Awaitility.await(), eliminating the race condition with doFinally that caused intermittent test failures.
• pr_build compiles and passes unit tests cleanly (the remaining failures are the known external test fixtures).
• Guava dependency cleanup across modules remains clean and modular.

Approved!

Re-review after cf2c7498: enumeration looks complete for the modules that actually inherit the root pom

Moving Guava out of the root <dependencies> and into the modules that consume it is the right call - the old arrangement put Guava on the compile classpath of every module in the reactor, including shenyu-spi and shenyu-alert, and made the re2j exclusion a global accident.

I checked completeness rather than trusting the file list, because a miss here is a compile error:

• Code search for com.google.common across apache/shenyu returns usage in shenyu-admin, the three admin-listener modules, client-core / client-grpc, common, disruptor, infra-redis, kubernetes-controller, loadbalancer, the plugin modules, protocol-grpc / protocol-tcp, register-client-beat / register-client-http, registry-apollo / etcd / zookeeper, sdk-core / feign / spring, the metrics starter, the sync-data modules and shenyu-web - all of which this PR touches.
• The modules that use Guava but are not touched do not inherit the shenyu root: shenyu-e2e has org.apache:apache:21 as its parent, and shenyu-examples inherits spring-boot-starter-parent and pins its own guava.version. Verified both, so no breakage there.
• Scopes match actual usage: the three admin-listener modules only import Guava in src/test, so test scope is correct; integrated-test-common uses it in ConfUtils (main) and is declared at compile scope.
• Moving the re2j exclusion into <dependencyManagement> is correct - the exclusion now applies to every consumer instead of only to the inherited dependency.

Non-blocking:

1. shenyu-integrated-test/* poms still inherit the shenyu root, so they are in scope for this change. shenyu-integrated-test-http and -common are covered; please confirm the remaining integrated-test siblings (sdk-http, dubbo/sofa/tars variants) either do not use Guava or declare it - they are built outside the default reactor, so CI will not tell you.
2. Worth running mvn dependency:analyze once on the full reactor after this lands; a module that used Guava only transitively will still compile but should declare it.

Same shared-CI-commit note as the sibling PRs: this branch carries the cryptor / SDK-route waits, so rebase after #7970 lands.

Requesting changes: this breaks the apache-dubbo integration test at runtime.

Evidence (head cf2c7498, it run 39707739026, job build (shenyu-integrated-test-apache-dubbo)):

Caused by: java.lang.NoClassDefFoundError: com/google/common/collect/Maps
  ... Factory method 'apacheDubboMetaDataHandler' ... MetaDataHandler

master (80adc159) is green on the same workflow, so the classpath gap is introduced here.

Why: shenyu-integrated-test/pom.xml dropped the compile-scope guava that every IT module used to inherit, and shenyu-integrated-test-apache-dubbo re-added it with <scope>test</scope>. That module is packaged by spring-boot-maven-plugin:repackage and the docker image is built from that fat jar, so a test-scope guava never lands in BOOT-INF/lib, while the gateway still needs Maps during context startup.

Worth checking before choosing the fix: the guava that shenyu-plugin-base and shenyu-plugin-apache-dubbo declare should have covered this transitively, yet it does not reach the repackaged image. Please look at the effective tree:

mvn -pl shenyu-integrated-test/shenyu-integrated-test-apache-dubbo dependency:tree -Dincludes=com.google.guava

Please either

1. keep guava at compile scope in shenyu-integrated-test/pom.xml (revert that hunk) until every IT module is verified individually, or
2. declare guava compile in the production module that actually references it, and set compile scope on the IT modules that need it at runtime.

Also: 8 of the 12 IT jobs on this run were CANCELLED (sdk-http, grpc, rewrite, https, spring-cloud, combination, tracing, sdk-apache-dubbo), so those are unverified — please re-run the full it matrix after the fix rather than relying on the cancelled jobs.

The rest of the refactor (root <dependencies> → <dependencyManagement>, per-module declarations, re2j exclusion move) still looks correct to me; this is purely about the IT runtime classpath.

Reviewed head 8b4dd57f. The blocking issue from my 2026-10-23 review is fixed and the evidence is now on the record.

Blocker — resolved

shenyu-integrated-test/pom.xml keeps guava at compile scope (version now managed by dependencyManagement), with a comment explaining why: the IT modules are repackaged into executable gateway jars, so a test-scope declaration never reaches BOOT-INF/lib while MetaDataHandler still needs com.google.common.collect.Maps at context startup. That is exactly the first option I offered, and the explanation in the POM means the next person to "clean this up" will know why it is there.

The full matrix confirms it. On this head all nine build (shenyu-integrated-test-*) jobs are green — including apache-dubbo, which was the NoClassDefFoundError: com/google/common/collect/Maps failure, and the eight jobs that were CANCELLED on the earlier run (sdk-http, grpc, rewrite, https, spring-cloud, combination, tracing, sdk-apache-dubbo). Everything else is green too: pr_build, rat_check, sql-matrix, registry_dependencies, build-docker-images, the whole e2e* matrix.

One thing I would like confirmed (not blocking)

The re2j exclusion moved from the root <dependencies> into <dependencyManagement>.

<dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
    <version>${guava.version}</version>
    <exclusions>
        <exclusion>
            <groupId>com.google.re2j</groupId>
            <artifactId>re2j</artifactId>
        </exclusion>
    </exclusions>
</dependency>

A managed exclusion is applied when guava is a direct declaration of the module, and it travels with the dependency node for transitive edges that pass through such a declaration. It is not applied when guava arrives purely from a third-party path that no shenyu module declares. Previously the root <dependencies> entry made guava a direct dependency of every module with nearest-wins resolution, so the exclusion was effective everywhere.

In practice I expect the outcome is unchanged, because every path I can see goes through shenyu-plugin-base, shenyu-web or shenyu-common, all of which now declare guava and therefore carry the exclusion. But the PR body only records that the two distributions contain exactly one lib/guava-32.0.0-jre.jar and lib/failureaccess-1.0.1.jar — it says nothing about re2j. Could you paste a before/after lib/ listing for admin-bin and bootstrap-bin, or at least confirm re2j is still absent from both? If it did reappear, that is a shipped-jar change that belongs in the description.

Two notes

• The description is ahead of the diff. It describes test fixes for tracing continuity, cryptor configuration errors, SDK 60-second route waits and ZooKeeper backend ports. None of those are in this head: the diff is 49 pom.xml files plus .github/workflows/integrated-test.yml. They were presumably dropped in a later push, but a reader cannot tell, and the accumulated validation log makes the change look much larger and riskier than it is. Please trim it to what actually ships.
• integrated-test.yml is an unrelated, good change. Printing docker compose ps --all and the last 200 log lines before exiting non-zero keeps the gate failing while making an unhealthy-container failure diagnosable. It has nothing to do with dependency scope though — please call it out on its own line in the description, or split it, so it gets reviewed as CI work rather than slipping through under a refactor(deps) title.

Cosmetic

Several POMs end up with a doubled blank line where the new block was inserted, e.g. shenyu-admin-listener-etcd:

        </dependency>

+
        <dependency>

Harmless, but git diff noise across 49 files.

Scope check

I verified the shape of the change rather than every one of the 49 files: root <dependencies> → <dependencyManagement> for guava, version managed centrally, re2j exclusion preserved, per-module declarations split 38 compile / 9 test, shenyu-integrated-test and shenyu-register-protocol handled explicitly. shenyu-common keeping a compile-scope declaration is correct and worth noting — it means downstream consumers still get guava transitively, so the win is hygiene for modules that do not depend on shenyu-common at all, which is what the title claims. No objection there.

Approving. Please answer the re2j question when you get a chance; I do not think it needs another review round.