mariuszs opened a new pull request, #11805: URL: https://github.com/apache/maven/pull/11805
## Summary Fixes the issue described in [maven-compiler-plugin#1042 (comment)](https://github.com/apache/maven-compiler-plugin/pull/1042#issuecomment-4063925384): when a dependency is both a direct dep (e.g., `modular-jar`) and a transitive dep of a processor, `ConflictResolver` removes the transitive occurrence before `TypeDeriver` can assign processor path types. The artifact ends up only on `--module-path`, missing from `--processor-module-path`. This builds on PR #11380 which introduced `TypeDeriver`. ### Root cause `ConflictMarker` keys on `groupId:artifactId:extension:classifier`. Since `modular-jar` and `modular-processor` both have `extension=jar, classifier=""`, they share the same conflict key. `ConflictResolver` (which runs before `TypeDeriver`) picks one winner and **removes** the loser entirely (verbosity=NONE). `TypeDeriver` then never sees the transitive processor occurrence. ### Fix: two-phase approach (no maven-resolver changes needed) | Phase | Transformer | When | What | |-------|------------|------|------| | 1 | `TypeCollector` | **Before** ConflictResolver | Walks pre-conflict tree, records `{GA:ext:cls → derived processor type}` in context | | 2 | `ProcessorTypeMerger` (in `TypeDeriver`) | **After** ConflictResolver | Reads context, sets `PROCESSOR_TYPE` property on surviving nodes that need both paths | | 3 | `DefaultDependencyResolverResult` | At path assignment | Reads `PROCESSOR_TYPE`, adds artifact to processor paths too | `TypeCollector` **short-circuits** when no processor-type direct deps exist, so builds without processors pay zero cost. ### Changes - New `TypeCollector` transformer (impl + compat) - New `PROCESSOR_TYPE` artifact property in `MavenArtifactProperties` - `TypeDeriver` enhanced with `ProcessorTypeMerger` inner visitor - `DefaultDependencyResolverResult.addDependency()` handles `PROCESSOR_TYPE` - `MavenSessionBuilderSupplier` wires `TypeCollector` before `ConflictResolver` ## Test plan - [x] New test `TypeDeriverWithConflictResolutionTest.sharedDependencyLosesProcessorType` — reproduces the exact scenario and verifies the fix - [x] Control test `typeDeriverAloneWorksCorrectly` — proves TypeDeriver logic is correct in isolation - [x] Existing `TypeDeriverTest` (2 tests) still pass - [x] Checkstyle: 0 violations -- 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]
