Hi. I'm having trouble understanding the difference in plugin's behavior depending on whether a

buildscript

block is used or not (or, at least, that seems to be the difference). I'm sharing the post from #CJYS1DAP5 for visibility because I assume the problem may be more generic and not necessarily Android related. https://gradle-community.slack.com/archives/CJYS1DAP5/p1753877427121339

What happens if in your second version • you move the

buildscript

block from the root build script to the

app

buildscript • or you add the plugin version in the version catalog, and replace the

buildscript

block in the root project with

plugins { alias(libs.plugins.room) apply false }

Does it work with the first and not work with the second?

> What happens if in your second version > • you move the

buildscript

block from the root build script to the

app

buildscript

FAILURE: Build failed with an exception.

* Where:
Build file '/blablabla/app/build.gradle.kts' line: 13

* What went wrong:
Plugin [id: 'androidx.room'] was not found in any of the following sources:

- Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
- Included Builds (No included builds contain this plugin)
- Plugin Repositories (plugin dependency must include a version number for this source)

---- > • or you add the plugin version in the version catalog, and replace the

buildscript

block in the root project with

plugins { alias(libs.plugins.room) apply false }

Same as before the change:

> Task :app:kspDebugKotlin
w: [ksp] Schema export directory was not provided to the annotation processor (etc.)

---- However, let me add I've just realized something new. Initially, I observed the problem in a different project (obviously) and started preparing a minimum reproduction project, and I noticed a strange difference between them. In the initial project, besides the KSP warning, the database schema file was not being generated (that's why my original post says so). But in the reproduction project it is being generated despite the warning, which is even more surprising...

Ah sorry, for the first of my bullet-points also remove it from

plugins

and use

apply(plugin = "androidx.room")

on top-level instead

Will check in a moment 🫡 Let me clarify my last message now. This is what I observed: 1. on branch where everything works normally ("method 1" from original post) 2.

git clean -xdf

3.

./gradlew :app:assembleDebug --rerun-tasks --no-build-cache --no-configuration-cache

4. all good 5.

rm -r app/schemas

to remove the generated DB schema file 6. switching to the branch where I'm getting the warning ("method 2") 7. IF a. I do run

git clean -xdf

now i.

./gradlew :app:assembleDebug --rerun-tasks --no-build-cache --no-configuration-cache

ii. schema file is not generated by the plugin b. I don't run

git clean -xdf

now i.

./gradlew :app:assembleDebug --rerun-tasks --no-build-cache --no-configuration-cache

ii. schema file somehow comes back 🤯

Argh, yeah, you also miss the accessors then of course, one moment

Here's the whole repro if anyone is interested: https://github.com/azabost/room-gradle-plugin-issue-repro

And additionally replace

room {

by

configure<RoomExtension> {

, then the configuraiton works also with the

apply

Btw.

room { ... }

inside

android { ... }

is just visual clutter.

Yeah, I figured out. I was following the official guide, which is obviously far from ideal...

If the official guide recommends that, it is buggy imho. Either it should add the extension to the android extension, or document to configure it on top-level. But adding the extension to top-level but then documenting to configure it within the android block is very inconsistent and wrong.

> And additionally replace

room {

by

configure<RoomExtension> {

, then the configuraiton works also with the

apply

With this, everything works fine, i.e. no KSP warning, and the schema gets generated correctly

Yeah, so I'd say it is a classloading topic.

But adding the extension to top-level but then documenting to configure it within the android block is very inconsistent and wrong.

Fully agreed. Can't count how many times I was mislead by this kind of documentation back in the groovy times, when it was less obvious.

In the working examples you add the plugin to the subproject classpath classloader

That's interesting, thanks for improving my understanding. Do you happen to know how could this be happening? I was under impression that the plugin will get applied, i.e. its apply(T) will be invoked, so it's internal logic will run, during the subproject's

plugins {}

block execution e.g.

// app/build.gradle.kts

plugins {
    id("com.android.application")
    // a few others
    id("androidx.room") // <--- now the plugin's apply(T) runs, no?
}

So my assumption would be that adding the plugin to root project's

buildscript

/ classpath wouldn't make any difference, because the plugin wouldn't really run at that point 🤔

Your assumption is correct, but that does not change anything in the classloader logic. With adding the plugin to the root project classloader it does not see the classes from the child classloader.

Btw. why do you add it to the root project via buildscript block at all?

I did it because in the other project they still have a lot of plugins in the root

buildscript

and I was exploring my options. I wanted to see if I can add the plugin and keep their old convention until they migrate away the whole root

build.gradle.kts

from

buildscript

usage

Plus you get type-safe accessors for Kotlin DSL when you use the

plugins { ... }

block to apply and it is the idiomatic and recommended way.

>

alias(libs.plugins.room) apply false

is like using the

buildscript

block to add the plugin to the classpath Yes, and the documentation for that plugin suggests doing so i.e. the

apply false

approach in root - that's why I was experimenting with

classpath

in

buildscript

as a replacement for that

I see, yeah, those two are equivalent and imho you should never do either unless technically necessary, otherwise it just uglifies the build logic.

If you would also move whatever plugin it requires - probably the android plugin - to the root build script classloader it would probably also work.

If you see the complete example, there actually should be Android plugin in root, inherited from `buildSrc/build.gradle.kts`(correct me if I'm wrong that root's classloader's parent is the

buildSrc

's classloader 😵 )

Hm, indeed, well, then it is not Android I guess, but something else

(if anyone reads it in the future and wonders how I know, here's the blog post I read some time ago)

As I have no idea where it is coming from at all, no

❤️ gradlephant 🥲

That's not interesting, but expected

Yeah, but then it means their documentation is completely wrong. Previously, I could justify the problem by thinking: "OK, they don't say to use buildscript block, so if I do it, then it's only my fault". but now I can see it doesn't even work in their scenario.

As I said, both are functionally equivalent