This message was deleted.

https://github.com/gradle/gradle/issues/16929 is the only one I know of

We havn't encountered any issues when moving to included builds for buildSrc in the elasticsearch build. worked like charm

Was there perhaps some other limitation related to version catalogs? Something like version catalogs not being accessible from within included builds?

referencing version catalogues from included builds is pretty well documented.

Ok so

versionCatalogs {
    create("libs") {
      from(files("../gradle/libs.versions.toml"))
    }
  }

Works within included builds too, right?

Of course

Ok, you convinced me 🙂 Opening another thread for this: https://gradle-community.slack.com/archives/CAHSN3LDN/p1652704917689839

Is there a specific reason (or reasons) to move from buildSrc to included build?

Several

Hmm, we use buildSrc for a lot of standard layout setup stuff. Do the gradle docs recommend moving from buildSrc to includeBuild?

I don't think so

I appreciate it.

https://developer.squareup.com/blog/herding-elephants/ mentions doing that

Yeah I did find https://publicobject.com/2021/03/11/includebuild/ on the topic

I didn't read it, what does it say to move to then?

If you need it in multiple projects (i. e. repos), I totally agree. If you use it as replacement for

buildSrc

in one project where all is committed together in one repo,

includeBuild

is fine. Always depends on the exact circumstances.

We have like 300 gradle projects, 80 of which have buildSrc. I'm thinking publishing a set of 'defaults' as plugins might fit our case, instead of everybody having pretty much the same buildSrc contents.

Sounds perfectly reasonable

Trying to assess whether switching

buildSrc

to an included build would actually benefit our specific use case. We only have a bunch of convention plugins in

buildSrc

, which are used by all subprojects so is it safe to say that:

buildSrc

runs always before the build, an included build only if it really is referenced

Switching to an included build would give us no benefit as the included build would still be referenced by all subprojects and therefore will always run.

buildSrc

result is prepended to the build script class path of all main build build scripts and thus also invalidates all tasks up-to-dateness or cache entry if anything changes, included build is only on the classpath of the build scripts where it is used

Switching to an included build would give us no benefit as the included build would still be referenced by all suprojects and therefore will always be in the classpath and will invalidate all subprojects when there are changes.

buildSrc

always also runs the tests, included build only runs the necessary work, that is builing the jar

In our specific use case, I actually prefer to always run the tests, because we have no dedicated tooling to run the tests of included builds automatically.

buildSrc

iirc cannot include other builds, included builds can

Not of concern in our use case.

buildSrc

is fixed where it is, included build can be wherever you like, like for example gradle/build-logic

Not of concern in our use case. Are there any other aspects from which we could benefit from switching to an included build?