yangjj-iso commented on issue #6602:
URL: https://github.com/apache/shenyu/issues/6602#issuecomment-6210177361
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:
```xml
<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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
