<type>processor</type> does not pick up annotation processor

[inaldt]

Affected version

4.0.0-beta-4

Bug description

While trying out maven 4 with the latest compiler plugin with my private project, I stumbled on something curious with regards to annotation processing.

Scenario:

• run ./mvnw compile in the root folder of this project
• expected: a class named MyGeneratedClass gets generated
• actual: no code gets generated

Note: said class does get generated if one uses the (now deprecated) AnnotationProcessorPaths element, as commented out in the pom of the clientproject subproject.

[desruisseaux]

The bug does not seem to be in the compiler plugin. Analysis:

• In a debugger, ignore the compilation of the first modules and focus on the last module: clientproject.
• In AbstractCompilerMojo.resolveDependencies(…), there is a call to Maven dependency resolver with a allowedTypes argument containing the following values: CLASSES, MODULES, PROCESSOR_CLASSES, PROCESSOR_MODULES.
• org.apache.maven.impl.DefaultDependencyResolver.resolve(DependencyResolverRequest) returns a list which does not contains the dependency of type processor, despite this type being requested by the compiler plugin.
• The dependency seems to be lost somewhere in org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate.collectDependencies(RepositorySystemSession, CollectRequest). The CollectRequest argument contains the processor dependency, but the DependencyResult return value does not.
• The problem seems to be in the call to doCollectDependencies(…) or in the lines that follow it.

Debugging is a bit difficult because of multiple dependency classes with objects wrapping other objects for historical reasons (a problem mentioned on the mailing list). Will need to try harder later.

[elharo]

An LLM investigated this issue and believes it understands 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}

[desruisseaux]

Isn't the root cause the fact that Aether does not take the type in account when deduplicating the JARs? Would it be possible to apply a fix there?

[elharo]

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.

[desruisseaux]

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.