Include in Dependency Report the path to the build file declaring the dependencies being reported on#189
Merged
Conversation
… dependencies being reported on
Use this link to re-run the recipe: https://app.moderne.io/recipes/org.openrewrite.recipes.rewrite.OpenRewriteRecipeBestPractices?organizationId=QUxML01vZGVybmUvTW9kZXJuZSArIE9wZW5SZXdyaXRl Co-authored-by: Moderne <team@moderne.io>
…#178) openrewrite/gh-automation#95 installs ~/.m2/settings.xml with `<mirrorOf>*</mirrorOf>` to route Maven through `artifactory.moderne.ninja` and avoid HTTP 429 from Maven Central. The mirror rewrites every repository request — including the test pom's deliberately-unreachable `<repository><url>https://nonexistent.moderne.io/maven2</url></repository>` — so the diagnostic recipe only sees the mirror and the local file cache. Neither Maven Central nor the test repo appear in the data table, and both assertions fail. Inject an explicit empty `MavenSettings` via `MavenExecutionContextView` (same pattern as `mavenSettingsWithMirrors`) so the recipe ignores `~/.m2/settings.xml` and sees the pom-declared repositories directly. The original three assertions are restored unchanged.
…DependencyInsight (#176) * Speed up ModuleHasDependency and RepositoryHasDependency by removing DependencyInsight Both recipes ran a fresh DependencyInsight visitor against every source file during scanning, which performs exhaustive Gradle + Maven dependency analysis just to answer a binary yes/no question about whether the module contains a given GAV. Replace the visitor with a direct check against MavenResolutionResult.findDependencies for Maven modules, and against GradleProject's configurations + ResolvedDependency.findDependency for Gradle modules. This mirrors the pattern Sam applied to the single-build-system versions of ModuleHasDependency in openrewrite/rewrite (commit 919c9f5 / PR #6664). These recipes are used as preconditions in many declarative migration recipes. Avoiding the DependencyInsight allocation + traversal per source file substantially reduces scanner time on repositories with many Java files. * Skip dependency scan in ModuleHasDependency once project is known to match Avoids re-running the per-tree dependency lookup for every source file in a module after the JavaProject has already been added to the accumulator. --------- Co-authored-by: Tim te Beek <tim@moderne.io>
Use this link to re-run the recipe: https://app.moderne.io/recipes/org.openrewrite.gradle.UpdateGradleWrapper?organizationId=QUxML01vZGVybmUgKyBPcGVuUmV3cml0ZS9PcGVuUmV3cml0ZQ%3D%3D#defaults=W3sidmFsdWUiOiI5LjUuMSIsIm5hbWUiOiJ2ZXJzaW9uIn0seyJ2YWx1ZSI6ImJpbiIsIm5hbWUiOiJkaXN0cmlidXRpb24ifSx7InZhbHVlIjoiYmFmYzE0MWI2MTlhZDYzNTBmZDk3NWZjOTAzMTU2ZGQ1YzE1MTk5OGNjOGIwNThlOGMxMDQ0YWI1ZjdiMDMxZiIsIm5hbWUiOiJkaXN0cmlidXRpb25DaGVja3N1bSJ9XQ== Co-authored-by: Moderne <team@moderne.io>
* Trust resolved version over declared dep in dependency search PR #179 extended ModuleHasDependency / RepositoryHasDependency to also match against requested/declared dependencies so they still match when resolution fails. This introduced false positives whenever a version range is supplied: the declared version string could satisfy the comparator even when the resolved version did not (e.g. a Gradle resolutionStrategy.force or platform alignment overriding the declared coordinate). - When a coordinate is present in the resolved dependencies, trust the resolved check and skip the declared-dependency fallback for that group:artifact. Only fall back for declared deps not already resolved. - Tighten versionMatches so a null declared version no longer auto-matches when a version constraint is supplied (same treatment as a ${...} property reference). Adds regression tests covering both rules in ModuleHasDependencyTest and RepositoryHasDependencyTest. * Apply suggestions from code review Co-authored-by: Jente Sondervorst <jentesondervorst@gmail.com> * Add Maven regression tests for BOM-managed dependency version range --------- Co-authored-by: Jente Sondervorst <jentesondervorst@gmail.com>
Use this link to re-run the recipe: https://app.moderne.io/recipes/org.openrewrite.AddToGitignore?organizationId=QUxML01vZGVybmUgKyBPcGVuUmV3cml0ZQ%3D%3D#defaults=W3sidmFsdWUiOiIuY29udGV4dC8iLCJuYW1lIjoiZW50cmllcyJ9XQ== Co-authored-by: Moderne <team@moderne.io>
* Fix `RemoveDependency.unlessUsing` for multi-module Maven projects `RemoveDependency` scans every source file and records whether `unlessUsing` matched against the file's `JavaProject` marker. In a multi-module Maven project the parent pom carries its own `JavaProject` distinct from the children, so the parent module's accumulator entry never reflects type usages found in child modules. The visitor would then strip the `<dependency>` from the parent pom even though child modules in the same reactor still relied on inheriting it. Now the scanner additionally records the `MavenResolutionResult.id -> JavaProject` mapping for every pom it visits. When the visitor is about to remove a `<dependency>` from a pom, it walks that pom's descendant modules via `MavenResolutionResult.getModules()` and preserves the declaration if any descendant's `JavaProject` shows the type in use. * Allow `RemoveDependency` to remove ancestor decl when descendants self-declare The descendant-aware preservation introduced in the previous commit was intentionally conservative: any descendant module whose Java sources used the `unlessUsing` type blocked removal of the dep from an ancestor pom. That over-preserves when a descendant module also declares the same dependency directly in its own `<dependencies>` — in that case the descendant is self-sufficient and the ancestor's declaration is dead weight. Refine the check: a descendant only blocks removal if it uses the type AND does not declare the dependency itself. The self-declaration check looks at the raw `requested` pom (as-written), not the resolved/inherited dependency list, so a child that inherits the dep from the ancestor we might modify still correctly blocks removal.
Use this link to re-run the recipe: https://app.moderne.io/recipes/org.openrewrite.xml.security.RemoveOwaspSuppressions?organizationId=QUxML01vZGVybmUgKyBPcGVuUmV3cml0ZQ%3D%3D#defaults=W3sidmFsdWUiOiIyMDI2LTA2LTE3IiwibmFtZSI6ImN1dE9mZkRhdGUifV0= Co-authored-by: Moderne <team@moderne.io>
Use this link to re-run the recipe: https://app.moderne.io/recipes/org.openrewrite.github.ChangeActionVersion?organizationId=QUxML01vZGVybmUgKyBPcGVuUmV3cml0ZQ%3D%3D#defaults=W3sidmFsdWUiOiJhY3Rpb25zL2NoZWNrb3V0IiwibmFtZSI6ImFjdGlvbiJ9LHsidmFsdWUiOiJ2NyIsIm5hbWUiOiJ2ZXJzaW9uIn1d Co-authored-by: Moderne <team@moderne.io>
…tion (#184) The Gradle/Maven dependency wrapper recipes (`AddDependency`, `ChangeDependency`, `UpgradeDependencyVersion`, `UpgradeTransitiveDependencyVersion`) each delegate to a Gradle and a Maven `ScanningRecipe`. Previously a fresh delegate instance was constructed on every `getInitialValue`/`getScanner`/`getVisitor`/`validate` call (and, in `AddDependency`, once per source file inside the scanner's `visit`). Each `ScanningRecipe` construction runs `UUID.randomUUID()` for its accumulator-message key, which draws from `SecureRandom` and dominated profiles of recipe-heavy runs. Memoize each delegate lazily on the wrapper recipe instance (a `final transient AtomicReference` that is excluded from the generated constructor and from `equals`/`hashCode`) so it is built at most once per wrapper instance and reused across the scanning and editing phases. The delegate is derived from the wrapper's options, so it belongs to the recipe instance rather than the accumulator: callers such as `rewrite-spring` deliberately reuse a single accumulator across two wrapper instances that have different options, so caching the delegate on the accumulator would reuse the wrong options. The `Accumulator` types are left unchanged, preserving their public constructors for downstream callers that build them directly.
The [Auto] Old GroupId migrations update (5253cf5) added a context note to the software.amazon.ion:ion-java relocation in migrations.csv. The RelocatedDependencyCheck recipe now surfaces that context both in the RelocatedDependencyReport data table row and in the inline search-result marker comment, so update the test expectations to match. Fixes the scheduled CI failure in run 28122079598.
…ansitive one (#188) * Keep direct dependencies whose scope or exclusions differ from the transitive one RemoveRedundantDependencies removed a direct dependency whenever a matched parent provided the same coordinate transitively, ignoring scope and exclusions. This silently changed the effective classpath when the direct declaration carried information the transitive entry did not. A direct dependency is now only removed when the transitive one provides it at the exact same effective scope and with the same exclusions: - Track each transitive dependency's effective exclusions and only treat a direct dependency as redundant when its exclusions match exactly. - Key Maven transitives by the parent dependency's own effective scope and compare against the direct dependency's effective scope, rather than treating a broader transitive scope as covering a narrower direct one. Fixes the five scenarios from openrewrite/rewrite#8235. * Simplify test POMs: drop XML declaration and project attributes * Extract handleGradle/handleMaven and trim comments * Rename getCompatibleTransitives to getCompatibleGradleTransitives
timtebeek
approved these changes
Jul 14, 2026
github-project-automation
Bot
moved this from In Progress
to Ready to Review
in OpenRewrite
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
7 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.
What's changed?
What's your motivation?
Anything in particular you'd like reviewers to focus on?
Anyone you would like to review specifically?
Have you considered any alternatives or workarounds?
Any additional context
Checklist