gnodet commented on PR #13628: URL: https://github.com/apache/maven/pull/13628#issuecomment-6274759187
Thank you for the effort put into this contribution, but after reflection, this approach is not acceptable for Maven core. **The fundamental problem** Calling `repositorySystem.collectDependencies()` inside `DefaultGraphBuilder` — for every project, at graph-build time, before any build phase — is incompatible with Maven's performance contract. The graph builder is deliberately designed to work from POM declarations only, without triggering artifact resolution. Introducing a full transitive resolution here would add remote metadata fetches and POM downloads to every build invocation on every project that has external dependencies. This is not acceptable overhead. The other alternatives I mentioned in my earlier review comments don't hold up either: - **Lazy/on-demand**: complicates the graph builder with `-pl` edge cases and ordering races - **Local-cache-only**: cold builds silently broken, cache state can be inconsistent - **Post-resolution fixup**: first build fails with a confusing error, unacceptable UX **The correct solution: declare the dependency explicitly** If your project depends on an external library that itself depends on a reactor module, the correct fix is to **add an explicit `<dependency>` on that reactor module in your POM**. This: - Makes the ordering constraint visible and documented - Keeps graph building O(direct dependencies) — no resolution needed - Is already the recommended workaround for MNG-7392 - Is the right design: implicit transitive coupling through external libs should be made explicit This is a "Won't Fix" from the Maven graph builder's perspective. The behavior is by design — the graph is built from declared dependencies, not inferred ones. Closing this PR and the linked issue accordingly. -- 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]
