Centralize Dependencies With Version Catalogs (Gradle best practice tip #20)

Take control of your Gradle dependencies with Version Catalogs. Reduce duplication and improve maintainability with this centralized dependency file accessible from any build script.

Death to build script duplication 0:00
How we used to do it 0:29
A centralized approach to Gradle dependencies 1:06
Adding a version catalog file 1:23
Referencing version catalogs from the build script 2:30
Two pro tips to using version catalogs 3:12

[SirWolf]

Why does this make things easier? More to type, adds extra indirection (I have to look into an extra file to check what I'm including), the file format isn't the simplest, and `ext` properties are also accessible by subprojects, and the Spring BOM plugin provided a similar feature. But I don't want to be so negative about it, usually I welcome new changes, and this one has upsides too. The new approach is more systematic and less programmatic, and a core feature of Gradle. It reduces arguments about how to define versions without repetitions. I just wish they have made it more compelling for me. Thanks for the info!

[DouglasRoberto_]

Nice video Tom. Is there any advantages of using catalogs instead of declaring dependencies and versions in Kotlin files inside buildSrc folder?

[Ric.Almeida]

How to reference Catalog from buildSrc scripts?

[AjayDewari]

Thanks for the video, Tom added toml file Lol

[axesspwns]

What exactly should I put in my toml file? I see that you added version number and libaries in this video. How about config variables like compile and min sdk?

[theanswersixers]

Nice video. Between this approach and Gradle's dependency locking feature, do you have any experience which works best (especially for a multi module project)?

[amm]

Hi Tom, great video but how can I still get notified when there's a newer release of the dependencies included in the toml file?

[OctaviusPelagius]

After a year, can we see something like a Spring Boot project using Kotlin as both codebase and DSL? I'm interested in how to play with the plugins section specially when it has something besides `id` like `java` or `kotlin`

[Nick-cxrs]

Where we put that fucking file . Gradle doesnt see

[kevinjohns]

Hi Tom, we have few of our jars whose name starts with capital letters and while executing the gradle build I get this following error " Invalid catalog definition.
Reason : Library aliases must match the following regular expressions : [a-z]([a-zA-Z0-9_.\-]).
Do you have any idea how can I solve this problem without changing the jar name or is there any way to resolve this via gradle files ?

BTW I am also using this libs.versions.toml file concept. It works fine for jars whose name follows the regex pattern but gives an error for the jar whose name starts with Capital letter.