Use version catalog.

[smillst]

Gradle version catalogs are a way to manage versions of dependencies added in Gradle 7. The version numbers are stored in gradle/libs.versions.toml. Renovate will update them (https://github.com/renovatebot/renovate/releases/tag/26.18.0). The nice thing about doing it this way is that this enables IDEs to provide autocompletion.

I did the conversion mostly automatically using by doing the following:

Add the following to setting.gradle

plugins {
   // See https://jmfayard.github.io/refreshVersions
  id("de.fayard.refreshVersions") version "0.60.6"
}

and then running:

./gradlew refreshVersionsMigrate  --mode=VersionCatalogOnly

Then carefully review the diffs because it changed a few thing not unrelated to version numbers. (Plus I had to manually change the plugin versions.)

[coderabbitai]

📝 Walkthrough

Walkthrough

This pull request migrates build configuration to a Gradle version catalog: it replaces hardcoded plugin IDs and dependency coordinates with libs catalog aliases across multiple subproject build.gradle files, removes several version properties from gradle.properties, and adds a new gradle/libs.versions.toml declaring plugins and library coordinates. No functional build logic or task configurations were changed beyond using the catalog references.

Possibly related PRs

• Reformat Gradle files. #7265: Edits the same dependency lines (e.g., annotated Guava/annotatedGuava) that were converted to catalog aliases in this PR.
• Update to the latest version of Shadow. #7331: Modifies Shadow plugin usage/version in build scripts, overlapping the plugin-to-catalog changes here.
• Put library version numbers in gradle.properties #7333: Centralizes version management and touches the same area of build-version sourcing changed by this PR (migration from properties to a catalog).

Suggested reviewers

• mernst

Pre-merge checks and finishing touches

✅ Passed checks (1 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 60db6b2 and bf13f9a.

📒 Files selected for processing (2)

• build.gradle (7 hunks)
• gradle/libs.versions.toml (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)

• GitHub Check: typetools.checker-framework (typecheck_part2_jdk25)
• GitHub Check: typetools.checker-framework (typecheck_part1_jdk25)
• GitHub Check: typetools.checker-framework (misc_jdk25)
• GitHub Check: typetools.checker-framework (nonjunit_jdk25)
• GitHub Check: typetools.checker-framework (junit_jdk25)
• GitHub Check: typetools.checker-framework (inference_part1_jdk25)
• GitHub Check: typetools.checker-framework (inference_part2_jdk25)

🔇 Additional comments (6)

gradle/libs.versions.toml (1)

1-77: Version catalog structure is clean and complete.

The catalog successfully consolidates all plugins and libraries into a central, maintainable location. The past issue regarding the missing google-java-format entry (flagged in prior reviews) has been resolved at line 71.

build.gradle (5)

1-20: Plugin alias migrations are correct and follow Gradle conventions.

The plugin declarations have been cleanly migrated to use version catalog aliases with proper naming conventions.

---

210-218: Dependency migrations to version catalog are correct.

The allprojects dependencies block properly uses catalog aliases for Error Prone and Javac dependencies, eliminating hardcoded versions.

---

829-829: Dependency migrations preserve existing exclusion logic.

The updates to requireJavadoc and annotatedGuava configurations correctly use catalog aliases while maintaining the existing exclude directive that prevents circular dependencies.

Also applies to: 961-965

---

575-582: Comment update correctly references the catalog alias.

The inline comment at line 579 has been updated to use the version catalog alias libs.error.prone.core, keeping documentation in sync with the build configuration.

---

118-134: The .get().version syntax on lines 126, 353, and 356 is correct. According to Gradle's version catalog documentation, library accessors return a Provider<MinimalExternalModuleDependency>, and calling .get() yields a MinimalExternalModuleDependency object with a .version property that contains the version string. String-based entries like "com.google.googlejavaformat:google-java-format:1.30.0" support this accessor and correctly extract the version component for the spotless formatter.

Likely an incorrect or invalid review comment.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

build.gradle (1)

118-134: Migrate googleJavaFormatVersion to version catalog and remove from gradle.properties.

The googleJavaFormatVersion variable remains in gradle.properties (line 8) and has not been added to gradle/libs.versions.toml, contradicting the PR's objective to centralize all versions in the catalog. This is actively used in build.gradle at lines 126, 353, and 356.

Add google-java-format to gradle/libs.versions.toml, remove googleJavaFormatVersion from gradle.properties, and update build.gradle to reference it from the catalog.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6ea17ed and ed94dd7.

📒 Files selected for processing (11)

• annotation-file-utilities/build.gradle (1 hunks)
• build.gradle (5 hunks)
• checker-qual/build.gradle (1 hunks)
• checker-util/build.gradle (1 hunks)
• checker/build.gradle (2 hunks)
• dataflow/build.gradle (1 hunks)
• framework-test/build.gradle (1 hunks)
• framework/build.gradle (2 hunks)
• gradle.properties (0 hunks)
• gradle/libs.versions.toml (1 hunks)
• javacutil/build.gradle (1 hunks)

💤 Files with no reviewable changes (1)

• gradle.properties

🧰 Additional context used

🧠 Learnings (1)

📚 Learning: 2025-11-02T02:18:00.536Z

Learnt from: mernst
Repo: typetools/checker-framework PR: 7354
File: annotation-file-utilities/tests/LocalMultipleManyMethodsShifted.java:14-14
Timestamp: 2025-11-02T02:18:00.536Z
Learning: In the Checker Framework repository, when doing refactoring PRs (such as preferring isEmpty() over size() comparisons), test files should not be changed. Tests should remain stable to preserve their exact patterns for annotation processing and bytecode verification purposes.

Applied to files:

• checker-util/build.gradle

🔇 Additional comments (15)

build.gradle (2)

1-20: Plugin declarations correctly migrated to version catalog aliases.

The conversion from hardcoded plugin IDs to catalog aliases is properly formatted and follows Gradle's accessor naming conventions (kebab-case in TOML → dot notation in code).

---

210-211: Core dependency migrations correctly applied.

All hardcoded dependency coordinates have been properly replaced with catalog references, and dependency exclusions are preserved. The comment on line 579 was updated in sync with the code change.

Also applies to: 578-579, 828-829, 960-965

checker-util/build.gradle (1)

9-9: Test dependency correctly migrated to catalog.

The junit test dependency reference resolves to the version catalog entry that uses version 4.13.2.

javacutil/build.gradle (1)

14-16: Plumelib dependencies correctly migrated to catalog references.

All three dependencies (hashmap-util, plume-util, reflection-util) are properly resolved through the version catalog.

framework-test/build.gradle (1)

6-6: Dependencies correctly migrated to version catalog.

Both libs.junit and libs.plume.util references resolve correctly through the catalog.

Also applies to: 10-10

framework/build.gradle (1)

38-67: All framework dependencies correctly migrated to catalog.

Ten dependency references have been properly converted and all catalog entries are defined and resolvable.

checker-qual/build.gradle (1)

3-3: Plugin declaration correctly migrated to catalog alias.

The biz.aQute.bnd.builder plugin version (7.1.0) is preserved in the catalog and properly referenced via alias.

dataflow/build.gradle (1)

11-11: Dataflow dependencies correctly migrated to catalog.

All three dependency references properly resolve through the version catalog, and the api designation for plume-util (reflecting that it's used in the public API) is preserved.

Also applies to: 13-13, 15-15

checker/build.gradle (6)

45-46: Verify dependency catalog entries exist.

These utility libraries are core dependencies. Confirm the catalog entries libs.reflection.util and libs.plume.util are defined correctly.

---

53-56: Verify AutoValue and Lombok catalog entries.

Confirm that all four dependencies are correctly defined in the catalog: libs.auto.value.annotations, libs.auto.value, libs.auto.value.parcel, and libs.lombok.

---

64-64: Verify javax.servlet, commons-io, and spark-sql catalog entries.

Confirm these three test dependencies are correctly defined in the catalog: libs.javax.servlet.api, libs.commons.io, and libs.spark.sql.

Also applies to: 66-66, 69-69

---

71-71: Verify junit catalog entry references correct artifact.

Confirm that libs.junit resolves to the correct JUnit library (likely junit:junit with an appropriate version).

---

6-6: No issues found—plugin alias is correctly defined and used.

The verification confirms the plugin alias com-gorylenko-gradle-git-properties exists in the version catalog and is properly referenced in build.gradle using the correct Gradle convention (hyphens in the catalog key transform to dots in the alias path). The version is correctly maintained in the catalog entry.

---

59-62: AWS SDK BOM configuration is correctly set up.

The catalog properly defines the BOM as a string module entry, and the ec2/kms artifacts intentionally lack versions in the catalog—they will be managed by the BOM imported via platform(). This pattern aligns with Gradle best practices for managing dependency versions.

annotation-file-utilities/build.gradle (1)

23-31: Verify all dependency catalog entries and Guava is annotated version.

Confirm: (1) all six catalog entries exist—libs.options, libs.plume.util, libs.reflection.util, libs.guava, libs.asm, and libs.junit; (2) libs.guava resolves to the checker-annotated library (org.checkerframework.annotatedlib:guava); and (3) consistency with identical entries in checker/build.gradle.

[mernst]

LGTM