Piotr Krzemiński
02/13/2023, 10:05 AMbuildSrc
. What’s the difference?mbonnin
02/13/2023, 10:06 AMbuild-logic
doesn't leak it's classpathbuild-logic
is less "special" than buildSrc
. I need included builds anyways so if I can spare my brain having to remember the intricacies of buildSrc
, I'm all for it (although there seem to be a small resurgence of buildSrc
as of lately I must say)Piotr Krzemiński
02/13/2023, 10:11 AMmbonnin
02/13/2023, 10:11 AMbuil-logic
also allows you to have more granularity, define multiple submodules and plugins and only invalidate those parts of the build that actually change. buildSrc
is a huge switch. Any change in there will invalidate all your buildPiotr Krzemiński
02/13/2023, 10:12 AMmbonnin
02/13/2023, 10:13 AMhfhbd
02/13/2023, 10:13 AMcheck
task of buildSrc isn't called when using build-logicPiotr Krzemiński
02/13/2023, 10:13 AMmbonnin
02/13/2023, 10:15 AMincludeBuild("build-logic")
And then in your root build.gradle.kts:
buildscript {
dependencies {
classpath("com.example.build-logic:build-logic")
}
}
Or something like thisthanksforallthefish
02/13/2023, 10:16 AMPiotr Krzemiński
02/13/2023, 10:16 AMbuildSrc
whatsoever?mbonnin
02/13/2023, 10:17 AMthanksforallthefish
02/13/2023, 10:17 AMmbonnin
02/13/2023, 10:17 AMAdam S
02/13/2023, 10:17 AMbuildSrc
much more simple, and there are edgecases that still don’t work with build-logic
mbonnin
02/13/2023, 10:18 AMAdam S
02/13/2023, 10:20 AMmbonnin
02/13/2023, 10:20 AMAdam S
02/13/2023, 10:22 AMmbonnin
02/13/2023, 10:25 AMbuildSrc
and includeBuild()
, just everything is an include()
Adam S
02/13/2023, 10:26 AMPiotr Krzemiński
02/13/2023, 10:26 AMbuildSrc
in https://github.com/krzema12/github-workflows-kt/ 😄I’m dreaming of a world where there’s no moreI remember from my days in Amazon that we had this Brazil build system. What was awesome about it was that a build-time dependency (or rather, a piece of logic) wasn’t different itself from a runtime or compile-time one. Only the way it was included by subsequent modules mattered. I miss it in GradleandbuildSrc
, just everything is anincludeBuild()
include()
Adam S
02/13/2023, 10:27 AMallprojects {}
or subprojects {}
PoisonedYouth
02/13/2023, 10:36 AMsubprojects {}
sections, where a lot of configuration is applied to all submodules even they does not need it.Vampire
02/13/2023, 10:55 AMbuildSrc
and an included build, many are straightened out with Gradle 8 where buildSrc
is made much more similar to an included build while it is still technically not an included build. For example starting with Gradle 8 you can call buildSrc
tasks from the commandline, tests are not run automatically, buildSrc
now can include other builds, init scripts are also applied to buildSrc
build, .... All these are not true for buildSrc
up to now.
So with the changes in Gradle 8, the differences are way less significant. Differences that still apply that I have in mind are:
• you do not get Kotlin DSL accessors for precompiled script plugins in included builds that you get for buildSrc
• buildSrc
classes and dependencies are automatically added to a parent class loader of all build scripts and thus there is no conflict resolution with dependencies you have in actual build scripts in case you do not move all build logic to buildSrc
• the location of buildSrc
is fixed and cannot be configured
I usually prefer included builds over buildSrc
because I can have the included build in gradle/build-logic
, can have included builds with common logic for the main build and the build logic build (should not be true anymore with Gradle 8 ), have proper conflict resolution for dependencies, and do not invalidate all build scripts just because one change in the build logic.
I personally only use buildSrc
for cases where it is necessary, for example to monkey-patch classes of plugins I use. Because buildSrc
classes are in a parent class loader of all build scripts, classes included in it win over the same classes in a plugin and thus can be used to fix problems like missing input / output annotations that cannot be fixed otherwise without a fixed plugin version.buildSrc
should usually not be more than renaming or moving the directory, adding an includeBuild
and maybe replacing the plugin accessors with applying by id
for precompiled script plugins. Everything else should basically work the same.PoisonedYouth
02/13/2023, 11:00 AMbuildSrc
is always the starting point and depending on the project, I transform it to includeBuild
Adam S
02/14/2023, 8:52 AMI personally only use buildSrc for cases where it is necessary, for example to monkey-patch classes of plugins I use.This sounds amazing. I didn’t know this was possible. Do you have an example?
Vampire
02/14/2023, 9:46 AMbuildSrc
, with the exact same package and name.
So copy over the original file, do the necessary changes and you are done.
buildSrc
is in the parent class loader of the build scripts, so the classes from there win due to the classloader delegation rules of Java that say that you first have to ask your parent classloader for a class before you load it yourself.compileOnly
should usually be enough for that iirc.mbonnin
02/14/2023, 10:01 AM> I personally only use buildSrc for cases where it is necessary, for example to monkey-patch classes of plugins I use.
> This sounds amazing. I didn’t know this was possible. Do you have an example?For a recent example, you could use monkey-patching to make Kotlin 1.7.20 compatible with Gradle 7.6 (there was a binary change that made MPP tests crash): See the code in this Youtrack
Vampire
02/14/2023, 10:07 AMAdam S
02/14/2023, 10:07 AMhfhbd
02/14/2023, 10:08 AMbuildScript.dependency.classpath("")
to overwrite a (bad) dependency?Vampire
02/14/2023, 10:09 AMmbonnin
02/14/2023, 10:09 AMbuildSrc
might be a classloader above buildScript.dependency.classpath
so can override more stuff?hfhbd
02/14/2023, 10:09 AMVampire
02/14/2023, 10:09 AMhfhbd
02/14/2023, 10:10 AM