Avoid overwriting parent pom from marker when going in child.#5821
Merged
Avoid overwriting parent pom from marker when going in child.#5821
Conversation
timtebeek
reviewed
Jul 29, 2025
rewrite-maven/src/main/java/org/openrewrite/maven/tree/MavenResolutionResult.java
Outdated
Show resolved
Hide resolved
timtebeek
reviewed
Jul 29, 2025
Comment on lines
234
to
236
| if (parent != null) { | ||
| parent.getProjectPomsRecursive(projectPoms); | ||
| } |
Member
There was a problem hiding this comment.
Hard to say if there could be any negative impact since we seem to be bubbling up; but from the call log above it seems we'd still visit a parent first. Given how minimal the change is here we can monitor for any effects downstream.
Contributor
Author
There was a problem hiding this comment.
it seems it is written to be able to go all directions and start at any entrypoint.
That's indeed the reason of my asking if we should first bubble up so that at least we always have the same result whatever pom you start from
timtebeek
approved these changes
Jul 29, 2025
timtebeek
approved these changes
Jul 29, 2025
Laurens-W
approved these changes
Jul 29, 2025
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
4 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.
Thanks for the helpful reproducers @xLitil
What's changed?
By only
putting if absent, the resultingMapnow contains the requested pom of the level in the hierarchy and not the deeper nested ones. As we make changes to the pom itself and not to the child's parent references, the update marker was failing to resolve due to a child's requested pom overwriting the parent requested pom.What's your motivation?
~/.m2/repository/org/apache/logging/log4j/log4j-bom/${log4j2.version}/log4j-bom-${log4j2.version}.pom#5673Anything in particular you'd like reviewers to focus on?
Should we rework the code to update all the child's parent references when removing dependency? I think this should suffice as the parents references are update in a later stage to the newly calculated parent. We just had to be able to calculate the parent which was failing.
Now I also wonder if we can ever come in the situation where we do not start from the parent in that marker building that Map as that would then use the nested one and not the parent However, we could easily traverse to the highest parent first before building the map resulting in always the same MAP/pom values to be present iso the entry point where you called the method. Traversing to
parent == nullfirst would mean some more loops, but also acceptable imho. That would be more correct.Anyone you would like to review specifically?
@timtebeek please see comment above and inform me what you think would be best
Related issues
Checklist