This message was deleted.

I wrote a blog post about it https://developer.squareup.com/blog/herding-elephants/

one of my favorite posts! I probably should I have asked my question differently - it’s more about what are the differences. i.e. - what features do I lose when making

buildSrc

an included build?

ish? Might be a worthwhile incremental step forward. First step is always to get your code to compile, then iterate to make it compile faster 🙂

so there’s really 3 pieces of logic that I need to be migrated: • dependencies/versions (handled by version catalogs, so we’re good here) • helper functions • plugins It seems that plugins will be handled automatically. I have plugins like

id(“com.conventions.library.android”

- but currently using the generated accessor -

com.conventions.library.android

. Do I lose this? I also have some helper extension functions. For example: // variant that will respect `local.properties

fun ProviderFactory.gradleProperty(project: Project, propertyName: String)

fun Provider<String>.mapBoolean(default: Boolean? = null): Provider<Boolean>

// looks up named task, or registers it if it does not exist

fun <T> TaskContainer.namedOrRegister(taskName: String): TaskProvider<T>

My initial thought is, after putting everything directly on the classpath like

dependencies(project(“:buildSource”))

to break it up like

:buildSource:helper-functions

and

:buildSource:plugins

. Then only put

:buildSource:helper-functions

on the global classpath. Or is there a better way to do this?

we actually do exactly that right now. My goal is to get rid of such helper functions entirely and rely solely on

plugins {}

for adding plugins from my included build. But I believe in making progress towards that incrementally

you lose accessor generation but you can create plugin aliases if you migrate to catalogs

oh nice! I would like to see enhanced IDE navigation for plugin aliases in that case. Would be nice to be able to cmd + B

com.conventions.library.android

and navigate directly to that plugin, but that’s a side note

IDE support has a long way to be completely polished. No wrong unresolved references, toml autocomplete, shortcut navigation to original files and not generated files and so on

question for you @tony : Given the following design:

:buildSource:helper-functions // on `buildScript { .. } classpath
:buildSource:plugins

Is

:buildSource

a multi-project build, or are

:buildSource:helper-functions

and

:buildSource:plugins

each single project builds?

Is :buildSource a multi-project build

yes. You almost always want multi-project builds, with empty root projects, except for the most trivial cases for your helper functions, moving them into a plugin is probably the most idiomatic way to do it from gradle's perspective. We have a small handful of such modules left in our build, which we add to the root

buildscript.dependencies.classpath...

One possible pattern for you is to have those modules be normal JVM library modules, add them as dependencies to your convention plugin modules, and ensure that a convention plugin (like

com.mycompany.base-plugin

is applied to all modules/projects in your main build. Thus you have your utility functions available everywhere. Having said that, what you should really strive for is declarative build scripts that don't use those functions directly at all. Rather, your plugins use them, and you elide this question entirely

so structure becomes:

// root (main) settings.gradle.kts
includeBuild(":buildSource) // multiproject

where the multi-project consists of two subprojects: •

:buildSource:plugins

•

:buildSource:helper-functions

And the main build’s root

build.gradle.kts

file declares:

buildscript { 
  dependencies {
    classpath(project(":buildSource:helper-functions"))
  }
}

And slowly migrating away from

:helper-functions

into

:plugins

where possible. I’m guessing it would be good to break apart

:plugins

eventually into dedicated subprojects for each plugin, too?

I don't quite recall, I think there may be some Kotlin ABI analysis that would prevent that, but you can experiment pretty easily