Was wondering when I should be using a precompiled gradle script from my buildSrc vs just having files in my project I apply (apply(from = “./module-list.gradle.kts”) vs placing module-list in buildSrc/src/main/kotlin for example).
Also, what’s the advantage of using the versions catalog as opposed to declaring my dependencies and their versions as constants in buildSrc?
Was wondering when I should be using a precompiled gradle script from my buildSrc vs just having files in my project I apply (apply(from = “./module-list.gradle.kts”) vs placing module-list in buildSrc/src/main/kotlin for example).
Always.
Well, I prefer an included build, for example in gradle/build-logic/ over buildSrc, but that’s not the point.
Script plugins like those have many quirks, especially with plugin application and class loading even with Groovy DSL.
With Kotlin DSL it is even worse, because you do not get type-safe accessors generated for script plugins, but you get them for precompiled script plugins for the plugins you applied using the plugins { ... } block, to just name a few of the details. In script plugins you also cannot use the plugins block, but have to use the legacy way to apply plugins.
Also, what’s the advantage of using the versions catalog as opposed to declaring my dependencies and their versions as constants in
buildSrc?
If you change one version in buildSrc, the classpath of all your build script changes and everything needs to be redone. If you change one version in the version catalog, only things that use that version need to be redone.
And besides that, it is the standard built-in way to do it, why using a self-invented wheel if you already have one mounted that does the work better? 