gnodet commented on PR #13400: URL: https://github.com/apache/maven/pull/13400#issuecomment-6275470949
Thank you for the thorough work here, @arturobernalg — the analysis of the problem is spot on, and the tests clearly demonstrate the issue. After reviewing this more carefully, I think we should close both this PR and the linked issue (MNG-6058). Here's the reasoning: **The root cause is architectural.** In Maven 3, `MojoExecutor.newDependencyContext()` unions all mojos' required scopes into a single set, resolves one dependency graph, and stores it on the shared mutable `MavenProject`. Each mojo then filters that single graph via `ArtifactFilter`. As cstamas noted in the issue (citing the [Resolver docs on common misconceptions](https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-7/common-misconceptions.html#misconception-no2-%E2%80%9Ctest-graph%E2%80%9D-is-superset-of-%E2%80%9Cruntime-graph%E2%80%9D)), the collected graph for compile scope is NOT a subgraph of the graph for test scope — they are fundamentally different graphs that need independent collection and mediation. **This can't be cleanly fixed for Maven 3-style plugins.** The `MavenProject.getArtifacts()` / `setResolvedArtifacts()` contract is inherently single-graph — there's one mutable `Set<Artifact>` shared across all mojos. This PR works around that by re-resolving and re-mutating the project for each mojo, but: - The project's artifact state becomes ephemeral — it corresponds to whatever the last mojo needed, not a stable view - It only handles test scope exclusion (hardcoded `TEST_SCOPES`), not the general case (e.g. runtime vs compile graphs also differ) - It can't use the proper `ResolutionScope` mechanism from MNG-8041 because of edge cases like `provided` overriding transitive deps (MNG-1233) - Anything reading `project.getArtifacts()` between mojo executions (lifecycle listeners, extensions) sees inconsistent state **This is already solved for Maven 4 plugins.** With `@Resolution(pathScope = "main-compile")`, each mojo field gets its own independent `DependencyResolverResult` via `DependencyResolver.resolve(session, project, pathScope)`. The resolver uses `Maven4ScopeManagerConfiguration` with proper `ResolutionScope` definitions. Results are cached per `(project, pathScope)` by the `RequestCache`. No shared mutable state, no scope interference. For Maven 3-style plugins running on Maven 4, the existing behavior is the expected (if imperfect) Maven 3 semantics. Changing those semantics risks breaking builds that have worked around the current behavior, as several commenters on the issue noted. The clean migration path is for plugins to adopt the Maven 4 API. _Claude Code on behalf of Guillaume Nodet_ -- 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]
