Keep direct dependencies whose scope or exclusions differ from the transitive one

[timtebeek]

• Fixes RemoveDuplicateDependencies - exclusions and scopes rewrite#8235

Problem

RemoveRedundantDependencies removed a direct dependency whenever a matched parent provided the same coordinate transitively, without checking scope or exclusions. This silently changed the effective classpath / exclusion contract whenever the direct declaration carried information the transitive entry did not.

The issue reports five scenarios (all against public Spring Boot starters) where the direct declaration must be kept but was incorrectly removed:

1. Direct dep has different exclusions than the transitive one.
2. Direct dep has no exclusions but the transitive one does.
3. Direct dep is compile while the transitive is test (direct is wider).
4. Direct dep is pinned to runtime while the transitive is compile (direct is narrower — nearest-wins means the direct declaration actually overrides the transitive scope).
5. The providing starter is provided, so its transitives are provided-only, but the direct dep is compile (wider).

Fix

A direct dependency is now only removed when the transitive one provides it at the exact same effective scope and with the same exclusions, so removal never changes the effective classpath:

• Each transitive dependency now tracks its effective exclusions; a direct dependency is redundant only when its exclusions match exactly.
• Maven transitives are keyed by the parent dependency's own effective scope (derived from getRequested().getScope(), deduped across the scope buckets a direct dependency appears in) and compared against the direct dependency's effective scope. The previous "broader scope covers narrower" logic is dropped for Maven, since a direct declaration at a different scope is not redundant.

Tests

Added the five scenarios from the issue as passing tests. All existing tests continue to pass (13 total).

[steve-aom-elliott]

Why did we end up dropping the differing scopes check for Maven and now only use the broader gradle scopes? I may have missed something here.

[timtebeek]

Good question — the short version is that Maven still checks scope, it just does it differently, so the widening helper is no longer needed there.

Maven (handleMaven): each direct dependency is now evaluated against transitives collected under its own declared scope, matched exactly:

Scope depScope = Scope.fromName(dep.getRequested().getScope());
Set<TransitiveDependency> transitives = scopeToTransitives.getOrDefault(depScope.name().toLowerCase(), emptySet());
if (isRedundant(dep, transitives)) { ... }

The scan phase keys the parent's transitives by the parent's own declared scope as well, so it's an apples-to-apples comparison. getBroaderMavenScopes only existed because the old code iterated maven.getDependencies() resolution buckets — where a compile dep also shows up in the runtime/test buckets — and keyed transitives by bucket; that mismatch is what needed reconciling. Keying by declared scope removes the need.

This is also a deliberate behavior change: we no longer treat a broader-scoped transitive as covering a narrower-scoped direct declaration, since that changes the effective classpath (e.g. dropping a direct runtime dep because a compile transitive provides it). It's locked in by keepsRuntimeTomcatEmbedCoreWhenTransitiveIsCompileScoped and keepsDirectCompileTomcatEmbedCoreWhenProviderIsProvidedScoped.

Gradle (handleGradle): still uses getCompatibleTransitives/getBroaderGradleScopes because there transitives are keyed by configuration name, and Gradle configurations genuinely inherit (testImplementation → implementation → api). A dependency in one configuration legitimately sees transitives from the configurations it extends, so we still walk those. Maven's flat declared-scope model has no such inheritance, so exact-scope matching is sufficient.

Happy to add a code comment making the Maven-vs-Gradle asymmetry explicit if that would help.

[steve-aom-elliott]

Maybe just a method rename to getCompatibleGradleTransitives or something like that. I guess I missed that it was no longer called by the handleMaven that was extracted.