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!
😶 2
m
mkrussel
07/27/2022, 10:04 PM
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.
g
Guilherme Delgado
07/27/2022, 10:08 PM
Good point, I don’t use buildSrc but I do use “build-logic” with conventions plugins which, in the end, are different projects.
m
mbonnin
07/27/2022, 10:17 PM
Tools like renovate or so might be able to process the toml files more easily than build.gradle
v
Vampire
07/28/2022, 7:15 AM
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.
j
Joffrey
07/28/2022, 8:31 AM
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.
m
mbonnin
07/28/2022, 8:34 AM
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
v
Vampire
07/28/2022, 8:50 AM
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.