elharo commented on issue #1031: URL: https://github.com/apache/maven-compiler-plugin/issues/1031#issuecomment-5095635480
Regarding where the fix should go: I believe it belongs in the **maven-compiler-plugin**, not in the Maven API or Aether. Reasons: 1. **The plugin already has this pattern** — `resolveProcessorPathEntries()` at `AbstractCompilerMojo.java:1637` resolves dependencies outside the main graph for the old `annotationProcessorPaths` mechanism. A similar method for `<type>processor</type>` would follow the same approach. 2. **The bug is in how the plugin consumes the API** — `resolveDependencies()` passes the whole `project` to the `DependencyResolver`, which naturally deduplicates. The plugin should inspect `project.getDependencies()` directly for processor-typed entries and resolve them separately, just as it already does for the deprecated element. 3. **Changing Aether/Maven API** to not merge duplicates with different types would be a much larger change with wide-reaching effects, and would couple Maven core to a compiler-plugin-specific concern (`processor` type semantics). 4. **Other plugins would still need the same** — any plugin that cares about processor types (surefire, etc.) would still need to handle this at their level even if the API changed. Concretely, the fix would go in the `ToolExecutor` constructor, between `resolveDependencies()` (line 278) and `resolveProcessorPathEntries()` (line 280), scanning `project.getDependencies()` for `processor`/ `classpath-processor`/ `modular-processor` entries, resolving them separately, and merging into the `dependencies` map. -- 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]
