This message was deleted.

org.gradle.api.GradleException: Error resolving plugin [id: 'org.jetbrains.kotlin.android', version: '1.8.21', apply: false]

My understanding is if you want to have a convention that configures android aspects of a project (or kotlin ones in kotlin-jvm modules), you need to import the plugins (?) as dependencies on your

buildSrc

module, so that you can expose the APIs used by the actual module build.gradle.kts files in your convention file.

Where do you have the

id("org.jetbrains.kotlin.android") version "1.8.21" apply false

?

So for example, I want to configure

android {
   testOptions {
      unitTests.all { isIncludeResources = true }
   }
}

For example, in a

android-conventions.gradle.kts

file. android won't resolve unless the android gradle plugin is added as a dependency to the buildSrc module. Is this correct or am I way off base?

my toplevel

build.gradle.kts

file

toplevel of what?

oh so like

project/
   buildSrc/
   moduleA/
   moduleB/
   build.gradle.kts <-- here

Ok, doesn't make too much sense to have it there at all, if you also have it as

implementation

dependency of your convention plugin in

buildSrc/build.gradle.kts

. You should remove those unless you have a concrete reason to add them which usually are just edge cases.

so adding them as a dependency to the buildSrc module is the same as applying them as a plugin?

That

android

does not resolve in your

android-conventions.gradle.kts

is because you only get type-safe accessors for plugins you applied in that same script in its

plugins { ... }

block

story of my life! I guess I should read some documentation and understand what all this is doing in a bit more detail. I might have to let the paint dry a little with this conventions stuff I suppose

You could have a look at https://github.com/jjohannes/idiomatic-gradle, that should usually follow better practices. Though it might be a bit too much abstraction at places for a small to average build.

Cheers @Vampire I'll check it out

I would have asked the same question. People sometimes tend to be imprecise with terminology and so I tend to ask for clarification to not waste time with wrong advices. 🙂 In both cases you could have meant top-level or root project of the build logic / buildSrc build, or of the production build. So in words "root project build script of the production build" would for example be clear if that is really what is meant too. 😄 Clearest is really showing the structure you talk about and then using the path or a pointer like you did in response to my question. 🙂

100% understand, I was just worried I might have missed some standard parlance somewhere! Cheers again @Vampire!