Skip to content

Supplement processor-module-path with module-path dependencies#1042

Open
mariuszs wants to merge 1 commit intoapache:masterfrom
mariuszs:fix/modular-processor-shared-deps
Open

Supplement processor-module-path with module-path dependencies#1042
mariuszs wants to merge 1 commit intoapache:masterfrom
mariuszs:fix/modular-processor-shared-deps

Conversation

@mariuszs
Copy link

Summary

Fixes #1039FindException when a modular-processor dependency transitively requires a module that is also a direct project dependency (declared as modular-jar).

Root cause: Maven's conflict resolution places a dependency on only one path type. When avaje-inject is declared as modular-jar (→ --module-path) and is also a transitive dependency of avaje-inject-generator (modular-processor--processor-module-path), it ends up only on --module-path. Since javac resolves the processor module layer independently, it throws FindException: Module not found.

Fix: After dependency resolution, copy --module-path entries to --processor-module-path when processor modules are present. This is safe because the processor module layer is isolated — additional modules don't cause conflicts.

Changes

  • ToolExecutor.java: Added supplementProcessorModulePath() method (~15 lines)
  • New integration test modular-processor-shared-dep/ that reproduces the exact scenario

Test plan

  • New IT modular-processor-shared-dep fails without fix (FindException), passes with fix
  • Existing ITs still pass

When a dependency appears both on --module-path (as a direct project
dependency with type modular-jar) and as a transitive dependency of a
modular-processor, Maven's dependency resolver places it only on
--module-path. However, javac resolves the processor module layer
independently, causing a FindException when the processor module
cannot find its required dependency.

This fix copies module-path entries to processor-module-path when
processor modules are present, ensuring javac can resolve all
dependencies needed by modular annotation processors.

Note: this applies only to modular paths. For classpath-based
processors, javac uses a single class loader that can see both
the classpath and the processor path, so no supplementing is needed.

Closes apache#1039
@mariuszs mariuszs force-pushed the fix/modular-processor-shared-deps branch from bb5a9ab to f8a6fd1 Compare March 15, 2026 19:38
@desruisseaux
Copy link
Contributor

I think that the analysis is correct and this pull request seems to address the issue, but as a workaround. Ideally, it seems to me that the issue should be addressed in Maven core or in Maven resolver. It would allow to add only the dependencies that were really requested, instead of adding all dependencies that could potentially have been requested.

I was hopping that apache/maven#11380 would help, but maybe it is only a first step. If I'm guessing correctly (I have not yet verified with a step-by-step debugging), the above-cited PR 11380 fixes the type of transitive dependencies when the type is only modular-processor, but we still have the issue that if a dependency is declared with both modular-processor and modular-jar types, only one of those types win while actually we need to keep both. @cstamas do yo think that this analysis is correct?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Dependencies of <type>modular-processor</type> fail if project uses them with a different type

2 participants