goutamadwant commented on issue #7306: URL: https://github.com/apache/maven/issues/7306#issuecomment-5470229576
@gnodet I reviewed the current plugin/core-extension resolution paths and the related issues. My understanding is that the core inconsistency still exists: - Project resolution uses a root artifact and adds direct dependencies explicitly. - Plugin and core-extension resolution use the plugin artifact as a root dependency. - The legacy scope selector therefore handles direct `test` and `provided` dependencies differently for projects versus plugins/extensions. A direct selector change would address that inconsistency, but it may expose the mediation problem described in MNG-5739: a direct `test` dependency can win over a transitive `compile` dependency and then be removed from the runtime classpath. MRESOLVER-8 and MRESOLVER-9 also appear relevant. MRESOLVER-10 is complete, and Maven 4 already supports transitive dependency management. PR #2000 seems complementary because it handles Maven core exports through plugin dependency management, but it does not address the root request and scope-selection difference by itself. I can work on this with the following plan: ### 1. Establish the behavior with regression tests Add focused integration tests covering: - A plugin with a direct `test` dependency. - A plugin with a direct `provided` dependency. - A core extension with the same cases. - A direct `test` dependency conflicting with a transitive `compile` dependency on the same artifact. - The equivalent `provided` versus transitive `compile` case. - Consumer-specified `<plugin><dependencies>` overrides. - Maven 3 and Maven 4 personality behavior. The tests would assert both the collected graph and the actual plugin/extension class realm. ### 2. Verify the Resolver boundary Confirm whether the current `ScopeDependencySelector.fromDirect(...)` behavior is sufficient for both request forms. If dependency selection still occurs before managed scope or optionality is applied, the corresponding Resolver behavior should be fixed and tested separately rather than worked around inside Maven core. ### 3. Unify Maven 4 plugin and extension resolution Prefer using the Maven 4 dependency resolver API and an explicit plugin resolution scope for both plugins and core extensions. The implementation must preserve: - Plugin dependency overrides. - Optional dependencies and exclusions. - Repository and mirror handling. - Existing dependency graph transformers and filters. - Plugin and extension realm cache behavior. - Maven core artifact filtering covered by MNG-5783. I would avoid changing the global repository-session selector because that could affect ordinary project dependency resolution. ### 4. Define compatibility explicitly The historical implementation selected behavior according to the plugin's Maven prerequisites. I would not reuse its old version threshold without agreement because it no longer represents the current Maven 4 compatibility boundary. Possible boundaries include: - Corrected behavior only with Maven 4 personality. - A plugin `requiredMavenVersion` boundary. - Another explicit compatibility switch. ### 5. Validate existing behavior In addition to the new regression tests, run the existing plugin and extension ITs, particularly: - `mng-5783-plugin-dependency-filtering` - `mng-5771-core-extensions` - `mng-4091` - `mng-4331` Then run the full Maven build and core integration-test suite. ### Proposed delivery I suggest splitting this into: 1. A regression-test PR defining the expected behavior. 2. A Resolver PR only if the tests prove a Resolver change is still required. 3. A Maven core PR unifying plugin and core-extension resolution. Before I start, should MNG-6135 be handled as part of MNG-8559/#10668, and which compatibility boundary would you prefer? I can begin with the test-only PR once that direction is confirmed. -- 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]
