Hello, What are the advantages and disadvantages from declaring the versions catalog in a .toml file vs “in-gradle”:

[versions]
some = "123"

[libraries]
my-lib = { group = "com.mycompany", name="mylib", version.ref="some" }

+

dependencyResolutionManagement {
    versionCatalogs {
        create("libs") {
            from(files("../gradle/libs.versions.toml"))
        }
    }
}

versus:

dependencyResolutionManagement {
    versionCatalogs {
        create("libs") {
            library("my-lib", "com.mycompany", "mylib").versionRef("123")
        }
    }
}

Personally I prefer separating in a .toml file and the “simpler” syntax, but other than that I couldn’t figure it out by reading this doc. Thanks!

One benefit of the .toml file is that it can be shared between projects. I used it to share versions between the main gradle build and the buildSrc project.

Good point, I don’t use buildSrc but I do use “build-logic” with conventions plugins which, in the end, are different projects.

Tools like renovate or so might be able to process the toml files more easily than build.gradle

What the others said, plus as a pro point for the API, you are more flexible if necessary, like combining sources into one catalog and so on.

I'm not 100% sure, but there might be a benefit for the TOML file regarding changes. Any change to the catalog in a gradle settings file or build file might force to rebuild more things than a change to the TOML file.

Was thinking about this too. It's true for Kotlin script (because the *.gradle.kts file needs to be recompiled). I don't think it's true in Groovy? The file being reevaluated each time and I don't think that invalidates the tasks themselves

iirc also the Groovy files are precompiled, would be ridiculous if not actually. So I think yes, if the settings script got changed, I think all tasks need at least to be reconfigured, but it shouldn't make them out-of-date I think, but not sure. With the TOML it is definitely better in that regard, yes.