4400 - gradle toml version catalogs

[KamilPatora]

What's changed?

• Added generic TomlTableValue support in rewrite-toml for reading and updating string-valued inline-table properties while preserving TOML structure.
• Extended ChangeDependency to update Gradle version-catalog libraries in gradle/libs.versions.toml, including:
  • inline-table group and name;
  • inline version;
  • referenced [versions] entries via version.ref.
• Extended UpgradeDependencyVersion to upgrade library versions in Gradle TOML catalogs:
  • string GAV notation;
  • inline-table version;
  • [versions] values referenced by version.ref.
• Extended UpgradePluginVersion to upgrade plugin versions in Gradle TOML catalogs:
  • string id:version notation;
  • inline-table version;
  • [versions] values referenced by version.ref.
• Added VersionCatalogToml, an internal Gradle utility for locating catalog tables, resolving [versions] values, and preserving TOML literal quoting.
• Added tests

What's your motivation?

Existing Gradle dependency and plugin recipes did not update dependencies declared in version catalogs.

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

Some cases that I did not cover, question is are they important for now or should they be developed later on:

• Shared version.ref entries

• Named catalogs and catalogs imported from arbitrary TOML paths are not supported (Support updating Gradle programmatic Version Catalogs #4852). This change targets Gradle’s conventional automatically discovered gradle/libs.versions.toml catalog only.

• Library aliases using module = "group:artifact" are not supported yet; this change recognizes the group and name inline-table form.

• Rich version declarations, such as version = { strictly = "..." }, require, prefer, or reject, are not supported. Only string versions and version.ref are handled.

• Catalog bundles are not updated directly. Recipes update the underlying library aliases, not [bundles] entries.

Anyone you would like to review specifically?

Have you considered any alternatives or workarounds?

We do have a project where we sometimes do some workarounds. For example, when we couldn't update toml using openrewrite's recipes:
https://github.com/allegro/allwrite/blob/e21ae8a7d2fc09a3b9707e46317fa1dc10ea407a/allwrite-recipes/src/main/kotlin/pl/allegro/tech/allwrite/recipes/gradle/ChangeGradleDependency.kt#L4

Any additional context

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

[timtebeek]

Thanks for kicking this off @KamilPatora ! I'd have perhaps expected more of these changes to land in the Gradle dependency trait we added a while back, but I'm not sure how far we've gotten with adoption there:

• Add GradleDependency trait #4394

My aim with the trait would be to limit which recipes even need to know about Toml specifically; ideally that's all handled by the trait and recipes just concern themselves with the question of bumping a version based on what's encountered. Perhaps @shanman190 has additional thoughts here as well. It's definitely a larger topic, but worth exploring to reduce complexity across recipes.

[KamilPatora]

Thanks for the feedback! I’ve only been working with TOML files for about a month, so I’m still getting a feel for how this should fit into the existing GradleDependency trait. Any ideas or guidance would be super welcome.

For now, I kept the TOML stuff in separate catalog traits since it’s a different AST model from build scripts.
Does that seem like the right direction @timtebeek?