From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

buildscript block is rarely needed.  Define the plugins by id in the plugins block.

where you have subprojects you can define the plugins directly, or create <https://docs.gradle.org/current/samples/sample_convention_plugins.html|convention plugins> to do that (and other cross-cutting configuration).

Gotcha thanks. And the next question would be if I have a plugin for a subproject which I want to define with a version stored in properties file, is it idiomatic to define the plugin under the root settings pluginManagement block with apply false and then define it in the subproject. Am I correct?

current convention is to define the plugin coordinates/version in version catalog (typically libs.version.toml) and reference that as needed.

But can I reference that within a subproject? From my understanding according the doc I can reference the version only within the pluginManagement

you can reference version catalog in subprojects.  Not sure where `pluginManagement` keeps coming from - it isn’t referenced in version catalog <https://docs.gradle.org/current/userguide/platforms.html|documentation>.

<https://docs.gradle.org/current/userguide/plugins.html#sec:plugin_management|https://docs.gradle.org/current/userguide/plugins.html#sec:plugin_management>

that’s settings/init scripts, a different (older) approach from version catalogs for defining versions.  Follow the guidance for version catalogs to setup plugin versions.

Thanks. I will check the new way to set up versions 


How can I understand what is the new and old way? Does the documentation informs which way is the newer one? 

they are both valid ways but serve different purposes.  For most projects - use the version catalog.  For advanced / special cases pluginManagement can be used.

Right. In my case I'm using for spinnaker plug-ins 

Btw. `apply false` within `pluginManagement { plugins { ... } }` is pointless.
That block does anyway not apply anything anywhere.
It only defines default versions for plugins if they are applied somewhere else in the build without version.
It is the old pre-version-catalogs way to centralize the version declaration for plugins.

am I right that when `libs.versions.toml` is present under `gradle`, is it not needed
```dependencyResolutionManagement```
defined in the `settings.gradle.kts`?

partially.  the `versionCatalogs` underneath there is typically not used when you have the toml file, though you could use it to have different catalogs, either defined in code or from different toml files.

you may still need `dependencyResolutionManagement` for other things, such as defining repositories.