This message was deleted.

Using

subprojects

is an anti-pattern; it couples projects together, resulting in limitations for parallel execution, configuration cache, etc. It’s cleanest to apply plugins in each project (as required for that project), or create convention plugin(s) that apply plugins / apply standard configuration (and apply those convention plugins in your projects). Plugins are applied project-by-project - they aren’t inherited from the root project.

@Chris Lee thank you for following up. I'am suprised that you state that plugins are not inherited - in the docs we found https://docs.gradle.org/current/userguide/plugins.html#sec:subprojects_plugins_dsl

that isn’t inheritance. In that example, it pulls a plugin onto the classpath (with a given version, not applying it). Sub projects then still have to apply it. There is no built-in mechanism to “apply this plugin to all projects” - if you want that, use the aforementioned convention plugin pattern (or apply plugins specifically on each project). This behaviour is desirable; not all projects are the same. Some may be libraries; others platforms; others non-Java; some published, some not; and so-on.

i would not argue that applying plugins on all projects forcefully does not make sense - understood. I just fail to understand the docs then. The docs define that by defintion, a plugin defined in

plugins{}

is automatically applied (in the docs there is the section

Where «plugin id» and «plugin version» must be constant, literal, strings and the apply statement with a boolean can be used to disable the default behavior of applying the plugin immediately (e.g. you want to apply it only in subprojects). No other statements are allowed; their presence will cause a compilation error.

under https://docs.gradle.org/current/userguide/plugins.html#plugins_dsl_limitations

No worries. That documentation is correct. It covers the case where you want to bring in the plugin on the root project (but not apply it), allowing it to be applied (by you) to subprojects. While you can do it that way (as documented), it’s often clearer to have convention plugin(s) that specifically applies what is required (incl. versions), leaving the root project relatively clean (perhaps it’s only role is to aggregate and package up artifacts).

using

plugins {}

, the plugins are applied very early. Using

apply:

they are applied depending on their position in the build file. obviously prefer

plugins {}

ok so basically

apply true

does mean 'apply on the project i'am define in' (so in our case, the root project.

apply false

then means, do declare (load into the classpath) but not apply. The latter is used to ensure all subproject can load (from classpath) without defining a custom version (so all subproject use the same version of a plugin)

You can also apply build script "fragments" which is what I did before "convention plugins" were a thing

I see, thank you a lot. both!

e.g.

apply from: project.file( "some/build/file.gradle" )

script plugins nowdays

if you want to ensure the same version of the plugin (without dirtying your root project), version catalogs can help there.

yeah convention plugins and version catalogs are our next milestone - so that one is on the roadmap

haha, i "mocked" version catalogs in Hibernate for years before that was a feature. so happy it is now a proper feature

they are, yes

no doubt. went through many gyrations of “do it yourself version management” before vc landed. Was happy to ditch all that plumbing!

anyway, good luck!

version catalogs? I do get auto completion (kotlin DSL).

sure, as i said... probably works great in kotlin scripts