fix: preserve processor path types across conflict resolution#11805
Merged
desruisseaux merged 1 commit intoapache:masterfrom Mar 28, 2026
Merged
fix: preserve processor path types across conflict resolution#11805desruisseaux merged 1 commit intoapache:masterfrom
desruisseaux merged 1 commit intoapache:masterfrom
Conversation
Member
|
Sorry for this, I rebased my PR without thinking and this one is now full of conflicts. |
Contributor
|
Hello @mariuszs . Would it be possible to rebase this pull request? |
Contributor
Author
Sure, rebased on current master. |
Member
|
LGTM! Thanks @mariuszs |
desruisseaux
added a commit
to Geomatys/maven-compiler-plugin
that referenced
this pull request
Mar 27, 2026
…/fix/modular-processor-shared-deps but taking only the test (no change in the compiler code). Instead, we rely on apache/maven#11805 for fixing the issue.
Contributor
|
Are we ready for a merge? I just verified that when this patch is applied, the test provided by apache/maven-compiler-plugin#1042 is fixed without any need for a hack in the compiler code. |
Contributor
Author
|
Yep, I'm all set on my end. |
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. This causes the artifact to appear only on --module-path, not on --processor-module-path (maven-compiler-plugin#1039). Fix: two-phase approach without changing maven-resolver: - TypeCollector runs BEFORE ConflictResolver, records which artifacts are transitive deps of processors in the transformation context - TypeDeriver (after ConflictResolver) reads the context and sets PROCESSOR_TYPE property on surviving nodes that need both paths - DefaultDependencyResolverResult reads PROCESSOR_TYPE and adds the artifact to processor paths as well TypeCollector short-circuits when no processor-type direct deps exist, so the vast majority of builds pay zero cost.
mariuszs
added a commit
to mariuszs/maven-compiler-plugin
that referenced
this pull request
Mar 27, 2026
…cies Regression test for apache#1039. The fix belongs in Maven core (apache/maven#11805).
Contributor
|
Hearing no comment, I will go ahead. |
|
@desruisseaux Please assign appropriate label to PR according to the type of change. |
desruisseaux
pushed a commit
to apache/maven-compiler-plugin
that referenced
this pull request
Mar 28, 2026
…cies Regression test for #1039. The fix belongs in Maven core (apache/maven#11805).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes the issue described in maven-compiler-plugin#1042 (comment): when a dependency is both a direct dep (e.g.,
modular-jar) and a transitive dep of a processor,ConflictResolverremoves the transitive occurrence beforeTypeDerivercan 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
ConflictMarkerkeys ongroupId:artifactId:extension:classifier. Sincemodular-jarandmodular-processorboth haveextension=jar, classifier="", they share the same conflict key.ConflictResolver(which runs beforeTypeDeriver) picks one winner and removes the loser entirely (verbosity=NONE).TypeDeriverthen never sees the transitive processor occurrence.Fix: two-phase approach (no maven-resolver changes needed)
TypeCollector{GA:ext:cls → derived processor type}in contextProcessorTypeMerger(inTypeDeriver)PROCESSOR_TYPEproperty on surviving nodes that need both pathsDefaultDependencyResolverResultPROCESSOR_TYPE, adds artifact to processor paths tooTypeCollectorshort-circuits when no processor-type direct deps exist, so builds without processors pay zero cost.Changes
TypeCollectortransformer (impl + compat)PROCESSOR_TYPEartifact property inMavenArtifactPropertiesTypeDeriverenhanced withProcessorTypeMergerinner visitorDefaultDependencyResolverResult.addDependency()handlesPROCESSOR_TYPEMavenSessionBuilderSupplierwiresTypeCollectorbeforeConflictResolverTest plan
TypeDeriverWithConflictResolutionTest.sharedDependencyLosesProcessorType— reproduces the exact scenario and verifies the fixtypeDeriverAloneWorksCorrectly— proves TypeDeriver logic is correct in isolationTypeDeriverTest(2 tests) still passmodular-processor-shared-dep) — 3-module project with shared-lib as bothmodular-jardirect dep and transitive dep ofmodular-processor, verifiesjavaccompiles successfullyRelated
FindExceptionwith modular processors)TypeDeriver(first step, but doesn't handle the conflict resolution case)