https://kotlinlang.org logo
#gradle
Title
# gradle
f

Feri Nagy

02/14/2023, 8:31 AM
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?
a

Adam S

02/14/2023, 8:43 AM
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.
Copy code
// ./buildSrc/.../AndroidFlavours.kt

fun AndroidAppExtension.myFlavourA() { .... }
fun AndroidAppExtension.myFlavourB() { .... }
fun AndroidAppExtension.myFlavourC() { .... }
and then use them in the project
Copy code
// ./my-android-app/build.gradle.kts
import myFlavourA
import myFlavourB
import myFlavourC

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

Feri Nagy

02/14/2023, 8:52 AM
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.
c

CLOVIS

02/14/2023, 8:53 AM
@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.
a

Adam S

02/14/2023, 9:09 AM
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.htmlhttps://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`
v

Vampire

02/14/2023, 9:52 AM
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.
138 Views