-
Notifications
You must be signed in to change notification settings - Fork 505
ChangeDependencyGroupIdAndArtifactId should not limit updating managed dependencies #5880
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
timtebeek
merged 7 commits into
main
from
ChangeDependencyGroupIdAndArtifactId-should-not-limit-managed-dependencies-by-version-only
Aug 27, 2025
Merged
Changes from all commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
f622c2c
ChangeDependencyGroupIdAndArtifactId should not limit managed depende…
jevanlingen b0fac3b
ChangeDependencyGroupIdAndArtifactId should not limit managed depende…
jevanlingen 67132ad
Merge branch 'main' into ChangeDependencyGroupIdAndArtifactId-should-…
jevanlingen 153c95a
Restore temporary
jevanlingen 19a98fe
Merge branch 'main' into ChangeDependencyGroupIdAndArtifactId-should-…
jevanlingen b1037b7
Put fix back
jevanlingen 4008aee
Merge remote-tracking branch 'origin/main' into ChangeDependencyGroup…
jevanlingen File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What has me slightly worried is that we're changing these values here from what they were (implied
false, true), to now explicitly setting the second tofalseto keep the test passing. That to me signals that we're changing the behavior in a way that might surprise folks using the explicit constructor, as we for instance do here:https://github.com/openrewrite/rewrite-migrate-java/blob/05fa3e0a9e228a4d5568702e36ac62ee0d4cf889/src/main/java/org/openrewrite/java/migrate/javax/AddJaxbRuntime.java#L221-L224
Can you explain why this change in default is needed, and what changes we should be making downstream as a result?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I'm mostly trying to look out for is that we don't inadvertently start to see more changes that we hadn't anticipated or desired following this change; and that's hard to say with just a single test added and the defaults flipped on three more. Just trying to make sure we can move forward with this with confidence.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
from what it looks like we're only sparsely using that recipe from Yaml; with no changes there expected (version was already used)
https://github.com/search?q=org%3Aopenrewrite+ChangeDependencyGroupIdAndArtifactId+language%3AYAML&type=code&l=YAML
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like this is the only downstream usage of the outdated constructor:
overrideManagedDependency=truerewrite-migrate-java#838There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I can explain this. The tests that I changed do not take managed dependencies into account. Thus by setting these managed properties to explicit false, the behaviour stays the same. This is in line with the thing I mentioned in the starting post: