[Task] No maven-enforcer-plugin anywhere #6602

Activity

1. Aias00

   added

   type: build

   priority: mediumMedium severityMedium severity

   on Aug 2, 2026
2. github-actions commented on Aug 2, 2026

   

   github-actionsBot

   on Aug 2, 2026 – with GitHub Actions

   Contributor

   More actions

   👋 Hello @yuluo-yx

   A new issue has been opened by @Aias00:

   • Title: [Task] No maven-enforcer-plugin anywhere
   • Link: [Task] No maven-enforcer-plugin anywhere #6602

   Please review when you have time. Thank you! 🙏
3. yangjj-iso commented on Oct 16, 2026

   

   yangjj-iso

   on Oct 16, 2026

   Contributor

   More actions

   I investigated this on commit 297ac6f849857bd0c2ad368709013e98494b0330 (2.7.2-SNAPSHOT). Enabling the suggested rules exposes existing dependency conflicts, so this needs a dependency-alignment plan as well as the plugin declaration.

   One clarification to the description: the effective POM already inherits an Enforcer execution named enforce-maven-version from org.apache:apache:21, requiring Maven 3.0.5. A repository-only grep misses that inherited execution. The proposed repository-owned Maven 3.6.3+/Java 17+ policy and dependency checks are still needed.

   For the experiment, I added maven-enforcer-plugin:3.6.3 to the root build/plugins, bound enforce to validate, with:

   <rules>
       <requireMavenVersion>
           <version>[3.6.3,)</version>
       </requireMavenVersion>
       <requireJavaVersion>
           <version>[${java.version},)</version>
       </requireJavaVersion>
       <dependencyConvergence/>
       <requireUpperBoundDeps/>
   </rules>

   No dependency versions or dependency exclusions were changed for this experiment. The wrapper uses Maven 3.6.3; validation ran on JDK 21.0.10. Java 17+ also preserves the existing Java 21 compatibility CI job.

   Results with that configuration:

   • ./mvnw -B -ntp -N validate passes all four rules and Checkstyle. This checks only the root project, so it is insufficient to establish reactor readiness.
   • ./mvnw -B -ntp -pl shenyu-common -am validate fails in shenyu-common with actual dependency-rule violations.
   • To inventory the whole reactor without stopping at the first violation, I ran ./mvnw -B -ntp validate -Denforcer.fail=false -Dcheckstyle.skip=true. In this local audit, 191 of 213 reactor projects reported dependency-rule violations: 15 distinct artifact coordinates for convergence and 36 for upper bounds, with 39 distinct coordinates across both rules. These counts include repeated transitive problems inherited by downstream projects; they are not 191 independent root causes. The audit's exit success is due to the diagnostic enforcer.fail=false override, not a clean dependency graph.

   The minimal shenyu-common reproduction already shows:

   Artifact	Observed conflict
   org.checkerframework:checker-qual	Caffeine 2.9.3 requests 3.19.0; Guava 32.0.0-jre requests 3.33.0. Both convergence and upper-bound checks fail.
   com.google.errorprone:error_prone_annotations	Gson 2.13.2 requests 2.41.0; Caffeine requests 2.10.0; Guava requests 2.18.0. Convergence fails.
   org.slf4j:slf4j-api	Dependency management resolves 2.0.13, while OSHI 6.10.0 requests 2.0.17. The upper-bound check fails.

   The full reactor additionally reports framework/BOM alignment problems, for example:

   • Spring Context resolves 6.1.10 while a transitive path requests 6.2.19.
   • Reactor Core resolves 3.6.7 while a transitive path requests 3.7.19.
   • MCP resolves 0.17.0 while Spring AI 1.1.8 requests MCP 0.18.3.
   • Other violations involve Jackson, Micrometer, ASM, Guava, OkHttp, Commons IO, Spring LDAP, and Elasticsearch.

   Unconditionally enabling both strict dependency rules therefore makes existing module builds fail immediately, even though root-only validation passes. Before proceeding with a PR, could maintainers confirm whether dependency alignment should be included in this issue, or handled through prerequisite fixes/staged rollout? Keeping dependency checks warning-only permanently would leave the drift guardrail incomplete.
4. Aias00 commented on Oct 16, 2026

   

   Aias00

   on Oct 16, 2026

   ContributorAuthor

   More actions

   Thanks @yangjj-iso — this is an excellent audit, and it changes how we should land this.

   Decision: staged rollout, not one bundled change.

   1. #6602 stays scoped to the plugin + version guardrails (hard-fail, safe).
   Confirmed your setup: the root POM inherits org.apache:apache:21, which already brings an enforce-maven-version execution pinned to Maven 3.0.5 (so a repo-only grep misses it — good catch), and <java.version> is 17. So #6602 will add a repo-owned maven-enforcer-plugin execution bound to validate with only the rules that already pass:

   • requireMavenVersion — <version>[3.6.3,)</version> (upgrades the inherited 3.0.5 floor to match the wrapper)
   • requireJavaVersion — <version>[${java.version},)</version> (17+)

   That delivers the build-time guardrail the issue is about, without breaking any module.

   2. Dependency alignment is tracked separately, not bundled into #6602.
   191/213 projects with violations is a cross-cutting change; folding it in would make the PR unreviewable and delay the safe win. I've opened #7679 to own it, seeded with your inventory.

   3. Staged enablement of the dependency rules (in #7679):

   • Stage 1 (transitional): land dependencyConvergence + requireUpperBoundDeps in report-only mode so drift is visible in CI without blocking builds.
   • Stage 2: align the graph via <dependencyManagement>/BOM, module by module.
   • Stage 3: flip both rules to hard-fail (globally, or per-module as each is cleaned).

   4. Warning-only is transitional, not the end state. Agreed — permanently leaving the dependency checks non-failing would leave the guardrail incomplete; the target is hard-fail once the graph is aligned.

   If you're happy with this split, would you like to open step 1 (plugin + version rules only, no dependency rules) as a PR against master? Please paste your shenyu-common minimal repro into #7679 as the starting point. Thanks again for the thorough investigation.
5. Aias00 commented on Oct 16, 2026

   

   Aias00

   on Oct 16, 2026

   ContributorAuthor

   More actions

   @yangjj-iso — following up on the plan above so we keep momentum: the step-1 PR for this issue is unblocked whenever you're ready.

   Scope (small, self-contained, passes as-is):

   • add a repo-owned maven-enforcer-plugin execution bound to the validate phase in the root pom.xml
   • rules: requireMavenVersion [3.6.3,) and requireJavaVersion [${java.version},) (17+)
   • no dependency rules, no <dependencyManagement> changes

   That keeps the diff reviewable and leaves the dependency-convergence work entirely to #7679.

   If you'd like to take it, just open the PR against master and reference this issue ([ISSUE #6602] ...). If you'd rather not pick it up, say so and I'll draft it myself so we don't block on it.

   Either way, please drop your shenyu-common minimal repro into #7679 so it can serve as the starting point for the alignment work. Thanks again for the thorough audit.
6. Aias00

   closed this as completedin #7680on Oct 17, 2026
7. Aias00

   added a commit that references this issue on Oct 17, 2026

   [ISSUE #6602] Enforce Maven and Java build requirements (#7680)

   ...

   7c99d60