This message was deleted.
# community-support
s
This message was deleted.
c
plugin versions can be defaulted in pluginManagement. not aware that plugin versions can be handled in dependencyResolutionManagement - that happens too late to handle plugin loading.
c
ah, yes, via version catalogs. that is the newest way, generally preferred.
e
Okay... will have to read more...
Reminds me of the Maven Dependency Management features...
j
It's technically both the same functionality. The version catalog just allows you to define plugin versions and versions of other dependency versions in "one place". Which is a feature many users requested when that was introduced. This place can be
dependencyResolutionManagement { 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:

https://youtu.be/8044F5gc1dE

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.