Fixed
Status Update
No update yet.
Comments
yb...@google.com
This error shows up when there is a module in your project whose .iml file does not contain:
external.system.id ="GRADLE"
Can you please check your .iml files? Also, instead of opening the project, *import* it, that will completely rewrite your .iml files and you won't see that error again.
Can you please check your .iml files? Also, instead of opening the project, *import* it, that will completely rewrite your .iml files and you won't see that error again.
ak...@gmail.com
I can confirm that it works with AS 0.8.14 if I do
1) open AS,
2) delete the Gradle Java modules from the project,
3) re-import the Gradle Java modules to the project,
4) close AS,
5) re-open AS.
In that case AS does not *not* complain about Gradle Java modules to be non-Gradle Java modules, and I've confirmed that the generated *.iml files containexternal.system.id ="GRADLE".
However, if I do
6) close AS,
7) delete the *.iml files,
8) re-open AS,
then AS again complains *although* the generates files again containexternal.system.id ="GRADLE". It seems that the problem is related to "open" vs. "import". In the latter instructions, the *.iml files seem to get implicitly generated because the Gradle Java modules are referred to from setting.gradle.
Can it be that AS is somehow performing the check for non-Gradle Java modules before the *.iml files are generated in case of just opening (instead of importing) the project?
1) open AS,
2) delete the Gradle Java modules from the project,
3) re-import the Gradle Java modules to the project,
4) close AS,
5) re-open AS.
In that case AS does not *not* complain about Gradle Java modules to be non-Gradle Java modules, and I've confirmed that the generated *.iml files contain
However, if I do
6) close AS,
7) delete the *.iml files,
8) re-open AS,
then AS again complains *although* the generates files again contain
Can it be that AS is somehow performing the check for non-Gradle Java modules before the *.iml files are generated in case of just opening (instead of importing) the project?
yb...@google.com
yb...@google.com
I see what is happening now. Yes, you are right. This is an issue with "open". I think I know how to fix this issue.
ak...@gmail.com
Thanks for the confirmation. On a more or less related note, as this would not have happened if I was committing the *.iml files, what is your recommendation WRT this? I know about [1] which recommends to share "All the .iml module files", but it's kind of annoying that these files get rewritten if e.g. dependencies change in build.gradle. In general, most of the *.iml files seem to be duplicate content WRT the build.gradle files and can be derived from them. So, should we commit *.iml files for Gradle Android modules to Git?
[1]https://intellij-support.jetbrains.com/entries/23393067
[1]
Description
Version used: 1.0.0-beta1
Kotlin 1.1.51
Gradle 3.0.0-beta6
Devices/Android versions reproduced on: Nexus 5 - Android Marshmallow (6.0.1)
The model (data) class:
@Entity(tableName = "class")
data class Class(
@PrimaryKey
var id: Long = 0,
var class_name: String = "")
Room fails in this case due to multiple constructors and suggests to use @Ignore. I'm not sure it's not picking the default constructor.
There are few workarounds for this problem:
1. Use @Ignore as suggested by Room.
2. Somehow it picks the appropriate constructor in this case:
@Entity(tableName = "class")
data class Class(
@PrimaryKey
var id: Long,
var class_name: String = "")
3. Switch to deprecated kapt.generateStubs = true. Instead of using apply plugin: 'kotlin-kapt'.
I wish Room could pick up automatically the default no-arg constructor and in case it doesn't then show error and then developer can either use @Ignore or the new annotation to select default constructor.