https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:build_sources Not directly related to spotless itself, rather spotless as an example for easier understanding. If I understand buildSrc correctly, it's isolated from the remaining builds. Thus, we can use buildSrc to configure all projects - except for buildSrc itself, as it is isolated. Meaning if I configure for example spotless via buildSrc, spotless itself is only applied to all projects except for buildSrc. Which is why one would have to run

./gradlew buildSrc:spotlessApply spotlessApply

to run spotless apply to both buildSrc and all projects. Given that buildSrc is isolated, there is probably no way to change this? (ChatGPT suggests a gradle task with exec but for many reasons that seems like an awful idea...)

Yes,

buildSrc

is more or less a separate stand-alone build that "happens" to be built before your main build and added to your build scripts class paths through a parent class loader. Yes, you cannot use things in

buildSrc

to configure the

buildSrc

build, that would be chicken-and-egg problem. Just in case, as it sounds a bit like that, doing anything in

buildSrc

will not apply anything to anything automatically. You just build custom build logic like convention plugins, that you then apply to those projects where you want those conventions to be used. With

buildSrc

you cannot depend on tasks from it from the main build, no. Using exec is a horribly bad idea of course, as the I in AI does not mean "intelligence", not in nowadays tools. If you would want to follow that approach, you would use the tooling API to drive the

buildSrc

build. But the better option would be to not use

buildSrc

, but - what I prefer anyway - a normal included build. With that you can make a dependency from an including build's task to an included build's task.

So instead of using buildSrc to create shared build logic for the whole project you would just use a regular project and depend on the regular project itself? Just asking out of curiosity because buildSrc is ... fascinating, as Mr Spock would say. ^^

Actually you just rename buildSrc to, say build-logic, and add an

includeBuild("build-logic")

to your settings script.

sounds to easy to be true. 😉 though.. just asking for opinions, why is build src recommended then? it makes me scratch my head. on one hand, I dislike ignoring conventions... on the other hand, buildSrc is - not meant negatively - due to its special rules hard to grok

There are not that many "special rules" since 8.0 there are only subtle differences between

buildSrc

and an included build and most only manifest if you need special things or in certain situations. But for most cases it is not really a noticable difference.

why is build src recommended then?

I don't recommend it. I would always recommend and prefer an included build unless forced to use

buildSrc

like when needing to monkey-patch 3rd party plugins. That it is used in most places in the docs does not mean it is recommended. It simply is longer around than included builds and a tiny tad easier to start with.