Understanding Gradle #09 – Centralizing Dependency Versions

Managing dependency versions isn't easy – these are options you have in Gradle: Dependency Constraints, Platforms, Catalogs & Version Locking.

▶️ 0:00 Motivation to centralize versions
▶️ 1:23 [Solution A] Putting constraints in convention plugins
▶️ 1:59 Why to use an alternative solution?
▶️ 2:54 [Solution B] Platform Projects
▶️ 3:45 [Solution B] Utilizing existing platforms (BOMs)
▶️ 4:35 [Solution B] Gradle plugin versions in platforms
▶️ 4:59 [Solution C] Dependency Version Catalog
▶️ 6:21 Differences between a Platform and a Catalog
▶️ 7:06 [Solution D] Dependency Locking
▶️ 9:26 Summary

Related Videos:

Further Readings:

[AvinashKumar-mhsi]

8:39 Inside the configurations closure, the things u put compileClasspath, runtimeClasspath.
How do you know, these sub-closures will be part of configurations closure. Please reply.

[thiamath]

Dependency locking is a really interesting feature... I'll have to study it deeper.
I think that the toml descriptors suits pretty well for most contraptions... lets see it they make it stable

[m.a.d.h.e.a.d]

Do I need to import a platform into every configuration where it is needed ( e.g. api(platform("…")) and implementation(platform("…")) )? Or is it enough to have only

[MartinSchmidt_INW]

Thank you very much! This was so helpful.

[fredeisele]

Are you planning on an update for version-catalog? I presume you would want to wait until the interaction with plugin development is completed.

[AliaksandrSmirnou]

is it possible to create platform as separate repo project and publish it into maven repo?

[ravikumargrandhi]

How should I exclude dependencies from libs.versions.toml file?

[grjpr]

What are the implications of applying some dependencies to all subprojects eg in the main build.gradle file, using the subprojects clause? It's easier to do then applying the plugin to all modules that need it, but are there any eg performance consequences?

[ilyastarchenko]

How centralizing dependency versions in microservice architecture on CI when every microservice is separate repository? I have GitLab CI and I don't know which approach the best for me. Platform is good but on every dependency version change(or adding new dependency) I have to publish it in Artifactory. Dependency version catalog is good too but I have to copy catalog from root repository inside my pipeline. Third solution is monorepo but it's impossible.

[tothethousandmiles]

Thanks for the content and effort in explaining this. it is certainly a help to have someone trying to explain what Gradle is.
I will use the chance to share some thoughts about Gradle as a tool. I have to say to me Gradle is an absolute junk and here is why:
first of all, a framework that does run on top of another framework does leave a lot to think in the way a solution is proposed, or a problem is solved. This means that for someone to learn this framework it has to have a basic notion if not advanced knowledge of maven as the documentation references to it on a high degree.
Second, it seems a framework it has been built by junior when you look at the criteria in solving certain aspects around dependencies, locking, transitivity etc.
3rd given the nature of the tool a developer needs to learn more than one tool to understand it in depth, this might well set devs in limbo when they are starting and therefore a lot of mistakes get made. No wonder why Gradle keep releasing versions.
It has been built with a coding perspective in mind and that is another problem; build a tool that all it supposed to do is set boundaries to compile, install application while facilitating a common ground all it does is set a very dirt land top start with, yes it was supposed to address some performance issues that maven brought at the time but the compromise seems too high to walk away in my opinion.
Please folk do yourself a favor, keep working on maven as that is the simplest way you can focus on the real problems you are trying to solve.
Worth to mention that maven has a very 3 solid version fully backward compatible that you cannot defeat.
Why I took the time to write these lines, because there is no other option if you want to build a better world. There is no point and sitting and complain about it and doing nothing. I hope this does not hurt any Gradle advocate it is not the intention of the comment.

[NikCimino]

Can you please make the same video, but for C++?