ftreede opened a new issue, #1063:
URL: https://github.com/apache/maven-enforcer/issues/1063
### Affected version
3.5.0
### Bug description
## Summary
With the default `excludedScopes` (`test`, `provided`),
`requireUpperBoundDeps` does not report a conflict where the lower version
comes from a test-scoped dependency. Because that path is shallower in the
dependency tree, Maven's "nearest definition" mediation picks the lower version
for the project, and it ends up on the runtime classpath (and in a Spring Boot
fat jar). The rule passes although the resolved version is lower than one
required by a compile-scoped dependency.
## Setup
- The project has a compile-scope dependency on `lib-a`. `lib-a` reaches
`com.networknt:json-schema-validator:3.0.8` (Jackson 3 based) through a long
chain of transitive dependencies, 5 levels deep.
- The project also has `org.wiremock:wiremock-jetty12:3.13.2` with
`<scope>test</scope>`. WireMock reaches
`com.networknt:json-schema-validator:1.5.9` (Jackson 2 based) in 3 levels. The
two major versions are not API compatible.
- No `dependencyManagement` entry for `json-schema-validator`.
## What Maven resolves
`mvn dependency:tree -Dverbose -Dincludes=com.networknt`:
```
lib-a (compile, deeper path)
\- (com.networknt:json-schema-validator:jar:3.0.8:compile - omitted for
conflict with 1.5.9)
wiremock-jetty12:test
\- wiremock:test
\- com.networknt:json-schema-validator:jar:1.5.9:compile
```
The shallower path through the test-scoped WireMock wins. `mvn
dependency:build-classpath -Dmdep.includeScope=runtime` lists
`json-schema-validator-1.5.9.jar` and no 3.0.8 jar, so the test-path version is
on the runtime classpath.
## What the enforcer does
```
mvn org.apache.maven.plugins:maven-enforcer-plugin:3.5.0:enforce
-Drules=requireUpperBoundDeps
```
Result: `RequireUpperBoundDeps passed`.
## Expected
The rule fails, because the resolved version (1.5.9) is lower than a version
required by a compile-scoped path (3.0.8).
## Likely reason it passes
Not verified in the rule's source: with the default `excludedScopes`, the
test-scoped path through WireMock is not considered, so only the 3.0.8 request
is seen and there is nothing to compare against. Maven itself still resolves
1.5.9 because that path is the nearest.
Evidence: with `test` removed from the excluded scopes,
```xml
<requireUpperBoundDeps>
<excludedScopes>
<excludedScope>provided</excludedScope>
</excludedScopes>
</requireUpperBoundDeps>
```
the rule fails and reports `com.networknt:json-schema-validator:1.5.9` with
the path `wiremock-jetty12:3.13.2 [test] -> wiremock:3.13.2 [test] ->
json-schema-validator:1.5.9` and a second path requesting 3.0.8.
## Impact
Excluding test scope by default makes sense for conflicts that exist only
among test dependencies (MENFORCER-276). Here the test-scoped dependency
decides the version of an artifact that a compile-scoped dependency also needs,
and the default configuration cannot see it. Users who run the rule to protect
a packaged application get no warning.
## Possible directions
- Document this limitation next to `excludedScopes`.
- Evaluate scope exclusion after mediation: ignore a test-scoped path only
if the resolved artifact is itself test-only, and still compare it against
compile-scoped requests.
--
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]
