desruisseaux commented on issue #1031: URL: https://github.com/apache/maven-compiler-plugin/issues/1031#issuecomment-5102149737
I would have the following counter-arguments: 1. **The plugin already has this pattern** — true, but only for compatibility with Maven 3 and in a deprecated method. When the deprecated method will be removed, the last trace of usage of this pattern will disappear. The reason for delegating to Maven Core instead is for more consistent behaviour between plugins. 2. **The bug is in how the plugin consumes the API** — I don't think so, because a design goal of the new API was that Maven Core would process all types at once. The reason is given in a "Design note" section of `DependencyResolverResult.getDispatchedPaths()` Javadoc. One reason is that some types are mutually exclusive, but not all of them. For example, it is okay to have `classpath-jar` and `classpath-processor` in same time, but it is not okay to have `classpath-jar` and `modular-jar` in same time. Another reason is that some types are ambiguous: should `jar` and `processor` be handled as modular or not? One difficulty of using modules with Maven 3 was that each plugins were making their own decision, and slight differences in the way that the decisions are made can result in `java` or `javadoc` executed with different class-path/module-path than the ones used by `javac`. Maven 4 shifts more decision (but not all) on Maven Core side in an attempt to reduce this problem. 3. **Changing Aether/Maven API** — yes, this is the biggest concern. But I'm not sure that this is a problem specific to the compiler. Maven 3 already needs to distinguish `jar` and `test-jar` for example. How is it done currently? (I did not verified). If nevertheless we want to keep current behaviour, we can add some internal flag which would enable the check of `<type>` only when Aether is used through the new API, and keep its current behaviour when invoked from the old API. This is indeed a complication, but I see that as a workaround for a technical debt and would be only temporary until the old API is removed. 4. **Other plugins would still need the same** — with the internal flag proposed above, other plugins would see no difference as long as they use the old API. -- 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]
