4400 - gradle toml version catalogs - #8274
Conversation
…-TOML-version-catalogs # Conflicts: # rewrite-toml/src/test/java/org/openrewrite/toml/ChangeValueTest.java
…s in Gradle TOML version catalogs
|
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: 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. |
…ted Gradle version catalog traits, keeping recipe logic focused on selecting replacement versions. Centralize shared version.ref updates
|
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. |
|
Apologies for the slow response here! In the case of Gradle and Toml I don't have all the answers, and with other work I've not found the time to dive in yet. |
…it and update dependency/version management
…local findTable method and improve quoted string handling
…ersion reference handling
…atalog: remove unused groupId and artifactId fields
…fields in indexConsumers method
…update path handling
… add tests for coordinate updates
…on declaration logic
|
Hey @timtebeek. Done some improvements here and there. I think this looks better than before... lol |
… handling in Gradle version catalog
2 participants
Summary
Adds Gradle Version Catalog support to the following recipes:
ChangeDependencyUpgradeDependencyVersionUpgradePluginVersionThe recipes can now recognize and update dependencies and plugins declared in the conventional
gradle/libs.versions.tomlcatalog in addition to declarations in Gradle build scripts.Implementation
This PR introduces semantic traits for Gradle Version Catalogs instead of embedding TOML-specific logic into individual recipes.
New traits include:
GradleVersionCatalogGradleVersionCatalogDependencyGradleVersionCatalogPluginThese traits model version catalog entries as dependencies and plugins, allowing existing Gradle recipes to operate on them using the same high-level concepts they already use for Gradle source files.
The implementation supports:
version = "...")version.ref)group:artifact[:version])module = "group:artifact"notationShared
version.refentries are updated conservatively. A referenced version is modified only when every consumer of that reference is supported by the recipe and resolves to the same replacement version, preventing unintended changes to unrelated catalog entries.Supported Scope
This PR supports the conventional Gradle version catalog located at
gradle/libs.versions.toml.Supported library declarations include:
group/namenotationmodulenotationversion.refSupported plugin declarations include:
version.refOut of Scope
The following are intentionally not supported in this PR:
strictly,prefer,reject, andrequire)GradleProjectmodel synchronization after catalog-only changesWhen an unsupported version declaration is encountered during a requested version change, the catalog entry is left unchanged rather than partially updating only its coordinates.
Tests
The test suite covers:
version.refupdatesversion.refcoordinationmodulenotationoverrideManagedVersionbehavior