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

Guilherme Delgado

06/21/2022, 3:15 PM
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 🙏
c

Chris Lee

06/21/2022, 3:25 PM
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.
👍 1
v

Vampire

06/21/2022, 3:43 PM
Or if you don't like a no-op plugin, you could add the dependency in the
buildscript { dependencies { ... } }
block.
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.
g

Guilherme Delgado

06/21/2022, 3:46 PM
v

Vampire

06/21/2022, 3:46 PM
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.
👍 1
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.
g

Guilherme Delgado

06/21/2022, 3:47 PM
yup that’s not the case, it’s my second migration, buildSrc to version.toml 🙂
in this case it’s for flavors dimension configuration, as shown in the link above
v

Vampire

06/21/2022, 3:48 PM
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.
g

Guilherme Delgado

06/21/2022, 3:49 PM
ok gonna give it a try and let you know 🙂 thanks for your answers so far!
👍 1
👌 1
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 🙏
👌 2
n

nuhkoca

06/29/2022, 12:20 AM
Hey @Guilherme Delgado could you please send me the sample code of how you fixed this? Thanks?
g

Guilherme Delgado

06/29/2022, 8:35 AM
basically they create plugins and by using (importing) them in the app/features modules gives you access to those classes/enums
follow the flavor sample
i’ve replicated this in my project since i have the same use case
n

nuhkoca

06/29/2022, 10:22 AM
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?
g

Guilherme Delgado

06/29/2022, 11:04 AM
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:
Copy code
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())
    }
}
Copy code
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”
v

Vampire

06/29/2022, 11:26 AM
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.
2
748 Views