Slackbot
10/25/2022, 11:10 PMChris Lee
10/25/2022, 11:25 PMEric Kolotyluk
10/25/2022, 11:26 PMChris Lee
10/25/2022, 11:28 PMEric Kolotyluk
10/25/2022, 11:28 PMEric Kolotyluk
10/25/2022, 11:29 PMJendrik Johannes
10/26/2022, 6:36 AMdependencyResolutionManagement { versionCatalogs { ... } } or a separate file gradle/ibs.versions.toml . Which again is the same thing. just different notations.
If you use the convention plugin approach to structure your build configuration - which means you do everything through your own plugins, you can also define the plugin versions in the dependencies of your own plugins. And for that you could than use a java-platform project with dependency constraints. Which is very much the same as de <dependencyManagement> block in Maven. (I have a larger example doing it like that here)
Gradle has many (probably too many) options for doing this right now. There is no clear "this is the best approach for every project" right now. So you can pick one.
Unfortunately it's really hard to get a good overview and it is confusing when you get started. I did this summary of the options to manage versions here:
I always say that it's important to have a central place for versions. (whichever feature you choose to do it)
And you can decide how "close" you want/need version management for Gradle plugins and dependencies of your product code. As the same mechanisms can be used for both.