ascheman commented on PR #820: URL: https://github.com/apache/maven-shade-plugin/pull/820#issuecomment-5016776680
@cstamas here you go — standalone reproducer (stock shade 3.6.0, no plugin build needed): https://github.com/aschemaven/mshade-819-reproducer `./run.sh <maven-home>` builds a tiny project (`test -> a (excl c); a -> b + b:alt; b -> c`, artifacts in a bundled file repo) and prints which deps in the generated `dependency-reduced-pom.xml` carry the exclusion. Results here: | Maven | b | b:alt | |---|---|---| | 3.9.16 (Resolver 1.x) | 1 | 1 | | 3.10.0-rc-1 (Resolver 2.0.20) | 1 | 1 | | 4.0.0-rc-5 | 1 | **0** | | 4.0.x-SNAPSHOT (e1f82346) | 1 | **0** | So @hboutemy's observation holds: same Resolver 2 line, different outcome — the delta is on the Maven side, not the resolver version. Two more data points from the reproducer: * `4.0.0-rc-5` with `-Daether.conflictResolver.verbose=true` → `b:alt` gets its exclusion back. That is effectively what this PR does, scoped to the single `collectDependencies` call in `updateExcludesInDeps` instead of the whole session. * Both 3.10.0-rc-1 and 4.0.0-rc-5 use `BfDependencyCollector` (per `-X`), so it is not the collector implementation either. What I don't understand myself yet: why 3.10's collected graph retains the duplicate `c` node under `b:alt` with verbose unset while 4.0's does not — that difference is exactly what the reproducer should let you dig into. On test coverage: the existing ITs (`dep-reduced-pom-exclusions`, `MSHADE-467_parallel-dependency-reduced-pom`) already cover this scenario and go red/green accordingly — once #810 enables the Maven 4 CI they become the permanent guard. The reproducer just takes the shade build out of the loop for bisecting the Maven side. -- 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]
