In my convention plugins included build I was adding dependencies as

compileOnly

(I think my idea was mainly leaving root module

plugins { }

as a single source of truth for putting plugins on classpath This approach seemed to work just fine until I decided to lift gcp build cache plugin out of

settings.gradle.kts

Now all of the sudden my android library convention plugin fails to resolve classes like com.android.lint How do I make sense of this and what’s the solution? My current intuition is that gcp build cache plugin being applied to settings was maybe putting com.android.library on classpath? Also if I decide to use implementation configuration for convention plugin dependencies does it mean I will need drop root module plugins with apply false and instead have versionless plugins in my build files?

having them in the root is probably still a good idea to deal with the classpath sharing so it is only loaded once at the root. I usually just do api or implementation in my plugin project, and the plugin project uses the same toml as the main build so they all have the same version anyway. Might not be the best way to do it when publishing plugins out for other repo's to consume but hasn't bit me the ass for our main mono repo yet

Just in case someone faces the same issue: My main idea was to provide dependencies for build-logic as

compileOnly

and actually put on the runtime classpath in root module

plugins { } block with apply false

I guess when I added a settings plugin and tried to use it I moved the point at which source code for build-logic is resolved to the settings.gradle.kts plugins { } block I solved the problem with splitting my build-logic build into

build-logic-settings

and b`uild-logic-project` If anyone knows a better solution I would love to hear it

Well, you can move the

plugins { } block with apply false

from the root project build script to the settings script instead. As long as you do

apply false

they are just added to the classpath but not applied, so it does not hurt that those are project plugins.

Haven't though about doing it in settings, makes sense to try, thanks Most important for is the fact I was able to pinpoint the problem because gradle errors were not helpful and in fact misleading, maybe it would be worth it to make a small reproducible example to report an issue with

I doubt there is much to fix on Gradle side. You try to access classes that are in a child classloader and those are just not found. Gradle can most probably not easily determine that the classes would be available in a child classloader to provide a more meaningful error message. It is similar to when you have a plugin in the root project that uses some classes of a plugin that are only added to the buildscript classpath in a subproject. Would be the same situation then.