elharo commented on issue #1031:
URL:
https://github.com/apache/maven-compiler-plugin/issues/1031#issuecomment-5092078879
I investigated this issue and believe I understand the root cause.
## Diagnosis
The problem is that **Maven's dependency graph merges duplicate G:A:V
entries during collection**, losing the `processor` type information.
### How it works today
1. When the project has two dependency entries for the same artifact (`jar`
and `processor`), both are passed to Aether's `CollectRequest`.
2. Aether deduplicates them by
groupId:artifactId:version:extension:classifier — since both resolve to
`library:jar:1.0-SNAPSHOT` with no classifier, they are **merged into a single
node**.
3. Only one set of artifact properties (from whichever entry wins in
conflict resolution) survives.
4. In `DefaultDependencyResolverResult.addDependency()`,
`dep.getType().getPathTypes()` is called. If the merged node carries the `jar`
type (the first entry in the POM), it returns `{CLASSES, MODULES}` instead of
`{PROCESSOR_CLASSES, PROCESSOR_MODULES}`.
5. The library JAR ends up only on `--module-path`, never on
`--processor-module-path`.
6. javac does not discover `TheProcessor`, so no code is generated.
### Why the old `annotationProcessorPaths` works
`resolveProcessorPathEntries()` (line 280 of `ToolExecutor.java`) resolves
those dependencies using a **separate** `DependencyResolverRequest` with
explicit coordinates passed via `.dependencies(coords)`. This bypasses the
project's dependency graph entirely, so it is not affected by deduplication.
The paths always land in `JavaPathType.PROCESSOR_CLASSES` regardless.
### What a fix would look like
The compiler plugin needs to also scan the project's *direct* dependencies
(from `project.getDependencies()`) for entries with `type=processor`,
`type=classpath-processor`, or `type=modular-processor`, resolve them
separately (similar to `resolveProcessorPathEntries`), and merge the resulting
paths into the `dependencies` map under the appropriate `JavaPathType`. This
would handle the case where a dependency is declared both as a regular jar and
as a processor.
### Relevant code
- `AbstractCompilerMojo.resolveDependencies()` (line 1576) — resolves
project dependencies with `pathTypeFilter`
- `ToolExecutor` constructor (line 276-282) — orchestrates dependency
resolution
- `DefaultDependencyResolverResult.addDependency()` — assigns path types to
individual dependency nodes
- `PathModularizationCache.selectPathType()` — selects best path type from a
node's declared types
- `DefaultTypeProvider.types()` — shows `processor` type maps to
`{PROCESSOR_CLASSES, PROCESSOR_MODULES}`
--
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]
