Feat: Align CP ordering with Maven 4

[cstamas]

This PR aligns classpath ordering with Maven 4 (level order). All Maven 2/3 versions released so far has "pre-order" flattening (historical reasons, Maven 2 did it like that). Maven 3.10.0 switches to Resolver 2, where resolver exposes flattening configuration too, and defaults to safer "level order", preventing issues like described here https://arxiv.org/abs/2407.18760v3

For resolver configuration, see configuration key aether.system.dependencyVisitor in
https://maven.apache.org/resolver/configuration.html If full Maven 3 behaviour needed, user can simply set -Daether.system.dependencyVisitor=preOrder and it restores CP ordering to that used in Maven 3.9 and older.

This PR changes:

• remove scattered "flattening" happening in multiple spots in Maven, it is (and in fact was, but result was thrown away) fully delegating to Resolver.
• simplify spots that was doing repeated deprecated pre-order flattening (which already happened in plugin dependencies resolver)

[gnodet]

Nice work aligning Maven 3.10.x classpath ordering with Maven 4 by delegating flattening to Resolver 2. The core refactoring is clean and consistent across call sites.

A few observations:

Scope drift: The getTransferStartTime() → getStartTime().toEpochMilli() changes in the two transfer listener files are a Resolver 2 API migration unrelated to classpath ordering. Consider splitting them into a separate commit (or PR) to keep scope clean and ease bisection.

Master porting: I compared against master (Maven 4) and the plugin dependency resolver refactoring is already done there — resolvePlugin() returns DependencyResult, callers use it directly, no PreorderNodeListGenerator anywhere. No porting needed for the core change.

However, there is one transfer listener inconsistency on master worth fixing separately: impl/maven-cli/.../Slf4jMavenTransferListener.java:91 uses Instant.ofEpochMilli(resource.getTransferStartTime()) while impl/maven-cli/.../AbstractMavenTransferListener.java:86 already uses the newer resource.getStartTime() directly. The Slf4jMavenTransferListener should be updated to match.

Note: this review does not replace specialized AI review tools (CodeRabbit, Sourcery) or static analyzers (SonarCloud).

Fully automatic review from Claude Code

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

[gnodet]

Question: on master (Maven 4), the equivalent method is named resolvePlugin() and resolveCoreExtension() already returns DependencyResult directly. The AndFlatten suffix is arguably more descriptive, but it introduces a naming divergence from Maven 4 — which is the opposite of the PR's stated alignment goal. Was this intentional, or would resolvePlugin / keeping resolveCoreExtension (with a changed return type) be preferred for consistency?

[cstamas]

I dont see resolveCoreExtension() on https://github.com/apache/maven/blob/bfc30f1fa89741fdafdfa26725b5e0795a619708/impl/maven-core/src/main/java/org/apache/maven/plugin/internal/PluginDependenciesResolver.java

But yes, those should be aligned, and new methods marked as @since 3.10.0

[gnodet]

This method is public but not declared on the PluginDependenciesResolver interface. BootstrapCoreExtensionManager calls it, so it depends on the concrete type. The old resolveCoreExtension had the same pattern, but since the interface is already being touched to add resolveAndFlatten, would it make sense to also promote this to the interface?

[cstamas]

Agreed, will add new (and old) methods to interface. I just did not want to "stir too much".

[cstamas]

Scope drift: fixed by #12328
Master porting: aligned master with #12329

PR comments applied as well

[gnodet]

All feedback from the first review has been addressed:

• Scope drift fixed: transfer listener changes extracted to #12328
• Master alignment: addressed via #12329
• Interface promotion: both resolveCoreExtensionAndFlatten and resolvePluginAndFlatten are now on the PluginDependenciesResolver interface
• Javadoc typo: fixed
• Bonus: BootstrapCoreExtensionManager now injects the PluginDependenciesResolver interface instead of the DefaultPluginDependenciesResolver concrete type — proper DI

The PR is now cleanly focused on its stated goal: delegating classpath flattening to Resolver 2 and aligning with Maven 4's level-order default. The refactoring is consistent across all call sites, PreorderNodeListGenerator is fully removed, and the escape hatch via -Daether.system.dependencyVisitor=preOrder is documented.

Note: this review does not replace specialized AI review tools (CodeRabbit, Sourcery) or static analyzers (SonarCloud).

Fully automatic review from Claude Code

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.