Skip to content

Kamil/gradle version catalog traits - #8699

Closed
KamilPatora wants to merge 13 commits into
openrewrite:mainfrom
KamilPatora:kamil/gradle-version-catalog-traits
Closed

KamilPatora wants to merge 13 commits into
openrewrite:mainfrom
KamilPatora:kamil/gradle-version-catalog-traits

Conversation

@KamilPatora

@KamilPatora KamilPatora commented Aug 28, 2026 •

Copy link
Copy Markdown
Contributor

What's changed?

  • Added document, library, and plugin traits for TOML catalogs.
  • Supported string and inline-table dependency/plugin entries.
  • Coordinated shared version.ref updates.
  • Centralized TOML table lookup and string accessors.
  • Preserved TOML formatting during updates.
  • Added validation for malformed module notation and versionless entries.

What's your motivation?

Provide a reusable, formatting-preserving semantic model for Gradle version catalogs and enable safe dependency, plugin, and shared-version updates.

Anything in particular you'd like reviewers to focus on?

Probably whole pr

Anyone you would like to review specifically?

Have you considered any alternatives or workarounds?

We do have our open-source 'version' of openrewrite where we handle TOML values: https://github.com/allegro/allwrite

Any additional context

Added positive and negative coverage for custom catalog paths, missing version references, versionless notation, malformed coordinates, visitor composition, and TOML quote preservation.

Checklist

  • I've added unit tests to cover both positive and negative cases
  • I've read and applied the recipe conventions and best practices
  • I've used the IntelliJ IDEA auto-formatter on affected files

@KamilPatora

Copy link
Copy Markdown
Contributor Author

MOved this from #8376, as I was using wrong branch from the fork

@jkschneider

Copy link
Copy Markdown
Member

Thank you for this work. Your commit is carried into #8864 with authorship intact, where the settings DSL and TOML forms of a version catalog are generalized into a single VersionCatalog trait. Closing in favor of that PR.

@github-project-automation github-project-automation Bot moved this from In Progress to Done in OpenRewrite Sep 12, 2026
jkschneider added a commit that referenced this pull request Sep 12, 2026
A version catalog has two homes, a `dependencyResolutionManagement { versionCatalogs { ... } }`
block in `settings.gradle(.kts)` and a `gradle/libs.versions.toml` file. `VersionCatalog.Matcher`
finds either, so `UpgradeDependencyVersion` upgrades the libraries of both through one visitor.

A shared version declaration is changed in place when every library referring to it is moving to
the same version and no plugin refers to it; otherwise the libraries that are moving detach to
versions of their own. A library whose metadata can't be downloaded is left alone and warned about
on the catalog.

Supersedes #8503 and #8699.

Co-authored-by: Alex Boyko <alex.boyko@broadcom.com>
Co-authored-by: Kamil Patora <kamil.patora@allegro.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

2 participants