Fixed
Status Update
Comments
da...@google.com <da...@google.com> #2
For Kotlin 2.0 and KSP 2.0 the Cannot change attributes of configuration ':composeApp:debugFrameworkIosX64' after it has been locked for mutation
really seems like a KSP issue. You should file a bug in their repository with a sample app if possible.
If you downgrade to Kotlin 1.9 then things 'should' work, there are example apps out there with such configuration, like the following one:
ap...@google.com <ap...@google.com> #3
Yes this does seem like a KSP issue however it only starts happening when room is added to the project. As the template project compiles just fine.
Will try to use the example provided by you to check if it fixes the issue.
Will try to use the example provided by you to check if it fixes the issue.
el...@google.com <el...@google.com>
na...@google.com <na...@google.com> #4
Note that this issue happens when applying the Compose, KSP and Room Plugin together in Kotlin 2.0.x, the workaround for now is to not use the Room Gradle Plugin and instead specify the schema location vis KSP arguments:
// In the build.gradle
ksp {
arg("room.schemaLocation", "${projectDir}/schemas")
}
Description
Component used:
androidx.room:room-compiler
Version used:
2.5.0-alpha02
,2.5.0-alpha03
Devices/Android versions reproduced on:
Samsung Galaxy S21 / Android 12
I've updated the Room version from
2.4.3
to2.5.0-alpha03
and after the last migration, the JSON generated will once in a while fail withAfter checking out the differences between the last schema file 73.json and the new one, 74.json, apart from the changes I've wanted to make, there's this block:
inside the only ftsVersion block I have. Whatever I write in the migration script doesn't matter, I always get the same issue. If I delete the .json, an identical one regenerates, which works fine the first time but then crashes the second time. What I've found is that if I delete the
SHADOW_TABLE_NAME_SUFFIXES
andshadowTableNames$delegate
blocks from 74.json, I don't get the issue anymore.I've attached a demo app in which I've reproduced the issue, however, I must mention that initially, it worked fine up to the 3rd database version. How I've managed to reproduce the issue on the demo app is as follows: