Hi. I am migrating `buildSrc` to an `includeBuild(...

# gradle

[Feri Nagy]

Hi. I am migrating buildSrc to an includeBuild(). Most of the logic is fine to migrate as it is reused in multiple modules, so we’ll put it in convention plugins. What I am struggling a little is where to put one-off logic that was extracted to buildSrc in order to slim down one build.gradle.kts file. We have an android app, that has ~20 product flavors for different configurations. Each flavor is defining stuff like applicationId, manifest placeholders, couple build config fields. All in all it is about ~250 lines of configuration. I don’t really want to add it to the convention plugins, as it is valid only for the single module, but I also do not enjoy the idea of adding it directly to build.gradle.kts. Do you have any suggestions? What would be the idiomatic approach here?

[Adam S]

if you had two Android apps, how much of those 250 lines would be copied between them? How many could be extracted out into a convention plugin?

I suspect it’ll be worth having a android-app.gradle.kts plugin, plus some specific configuration in the actual project

You could also extract the config out, but not into a convention plugin. For example, if you made a buildSrc/src/main/kotlin/AndroidFlavours.kt and had a bunch of extension functions for the configuration.

// ./buildSrc/.../AndroidFlavours.kt

fun AndroidAppExtension.myFlavourA() { .... }
fun AndroidAppExtension.myFlavourB() { .... }
fun AndroidAppExtension.myFlavourC() { .... }

and then use them in the project

// ./my-android-app/build.gradle.kts
import myFlavourA
import myFlavourB
import myFlavourC

android {
  myFlavourA()
  myFlavourB()
  myFlavourC()
}

[Feri Nagy]

if you had two Android apps, how much of those 250 lines would be copied between them?

Out of these 250, none. The actually reusable stuff would go to a convention plugin in build-logic.

You could also extract the config out…

That is pretty much how we have it now. But like I said, I want to move it from buildSrc and again, it does not feel right to have myFlavourA() extension in there, if it can be used only by a single module.

[CLOVIS]

@Feri Nagy IMO if it's used in a single module, it's fine to put it in that module's build.gradle.kts . It makes it clear that this module is special.

[Adam S]

Out of these 250, none.

Then keeping those lines in the Android subproject’s build.gradle.kts makes sense 👍

There’s a few blog posts that I like that kind of go over this stuff (usually by comparing it to Maven)

• https://melix.github.io/blog/2019/11/gradle-scripting.html
• https://melix.github.io/blog/2021/12/composition-in-gradle.html
the gist is that declarative stuff (dependencies, flavours, etc) go into a project’s build.gradle.kts, while non-specific configuration goes into `buildSrc`/`build-logic`

[Vampire]

If you want it neither in build-logic, nor directly in the build script, you can also just have another included build just for those 250 lines.
Or a separate subproject within the build-logic build.