I’m in the process of migrating from buildSrc to build-logic, and I was studying <idiomatic-gradle> ...

# gradle

[Guilherme Delgado]

I’m in the process of migrating from buildSrc to build-logic, and I was studying idiomatic-gradle and also Google’s now-in-android repository. But I’m having a problem, in buildSrc I’ve classes and enums that can be accessed by any module’s build.gradle.kts , but when using build-logic, I can’t share them, it throws org.gradle.internal.exceptions.LocationAwareException. Surely I’m doing something wrong because Google’s sample uses it with no problem here, but I don’t know what’s missing 😞
Any hint? Thanks 🙏

[Chris Lee]

one difference between buildSrc and build-logic: buildSrc is implicitly on the classpath of all projects. To get the same behaviour from build-logic, you can create an empty plugin (in build-logic) and reference that in projects.

[Vampire]

Or if you don't like a no-op plugin, you could add the dependency in the buildscript { dependencies { ... } } block.

[Vampire]

But another thing to keep in mind, if you have classes in build-logic that you want to use in some build script without a plugin form build-logic being applied there (or just the no-op plugin), you are maybe doing something wrong, especially if you want to be idiomatic.

[Guilherme Delgado]

I was trying to achieve this behaviour: https://github.com/android/nowinandroid/blob/1ac9cc071569b1edc51531b6da8de4f7f4da958b/app/build.gradle.kts#L71

[Vampire]

And idiomatic build script should optimally not contain any logic, `if`s, and so on.
It should more be a declarative DSL where you describe what you want not how to do it.
Gradles built-in plugins usually follow this approach.

[Vampire]

If it for example is about having a "version" enum where you define dependency versions, neither buidSrc nor build-logic is the tool of choice for that, but use a version catalog instead.

[Guilherme Delgado]

yup that’s not the case, it’s my second migration, buildSrc to version.toml 🙂

[Guilherme Delgado]

in this case it’s for flavors dimension configuration, as shown in the link above

[Vampire]

Yeah, ok, then what we said above. 🙂
You have to somehow bring your dependency on the build script classpath, either with a no-op plugin as @Chris Lee suggested, or explicitly using the buildscript block.

[Guilherme Delgado]

ok gonna give it a try and let you know 🙂 thanks for your answers so far!

[Guilherme Delgado]

Hi folks, so the “no-op” plugin approach suggested by @Chris Lee worked. I didn’t use a “no-op” because the app module imports plugins with logic so the “name space” was resolved by them 🙂 (looking at google’s approach I believe they achieved the same).
Regrading @Vampire class path approach, I couldn’t make it work 😕 probably i’m using a wrong syntax to import my local plugin 🤔

Nevertheless, thanks for your time guys 🙏

[nuhkoca]

Hey @Guilherme Delgado could you please send me the sample code of how you fixed this? Thanks?

[Guilherme Delgado]

Hi!
Follow this example, it’s better: https://github.com/android/nowinandroid/tree/main/build-logic

[Guilherme Delgado]

basically they create plugins and by using (importing) them in the app/features modules gives you access to those classes/enums

[Guilherme Delgado]

follow the flavor sample

[Guilherme Delgado]

i’ve replicated this in my project since i have the same use case

[nuhkoca]

Thanks @Guilherme Delgado my case is exposing an extension function on the BuildConfigField to other Gradle scripts to use it. Do you have such scenario?

[Guilherme Delgado]

I don’t know what you mean by “exposing an extension function on the BuildConfigField ” but i do have extension functions shared across gradle scripts, example:

internal fun Project.addComposeDependencies(libs: VersionCatalog) {
    dependencies {
        add("implementation", libs.findBundle("androidx.compose").get())
        add("implementation", libs.findBundle("accompanist").get())
        add("implementation", libs.findLibrary("helpers.coil").get())
    }
}

class AndroidLibraryComposeConventionPlugin : Plugin<Project> {
    override fun apply(target: Project) {
        with(target) {
            pluginManager.apply("com.android.library")
            val versionCatalog = extensions.getByType<VersionCatalogsExtension>().named("libs")
            ...
            addComposeDependencies(versionCatalog)
        }
    }
}

and I import it too in the “ApplicationConventionPlugin”

[Vampire]

Whatever code you have.
If you either apply a plugin - even if it does not do any actions, or if you manually add the dependency to the build script class path, the code is available in the build script and can be used.