Can't Repro
Status Update
No update yet.
Comments
ch...@theisolationist.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.
jk...@google.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?
ch...@theisolationist.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.
gk...@google.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]
ry...@google.com
It is better not to add iml files to source control. For regular IDEA projects is OK because .iml files are the source of truth for project configuration. In the case of Android projects, the source of truth is gradle.build files, and .iml are generated from them every time you sync your project with Gradle.
Description
The addition of support for libraries is fantastic however its utility is limited by the fact that only Functions are exported.
Is it possible to add the capability to export Types and Functions through the libraries?
Notes:
The libraries that I have built are based on the simple js inheritance model created by John Resig (
DataStore = Class.extend({
init: function( name, ss ) {
this.ss = ss;
this.tables = [];
this._createTables( ss.getSheets().map( function(sheet) { return sheet.getName(); }));
this._initialiseTables();
});
MemberDataStore = DataStore.extend({
init: function() {
this._super( "Member", SpreadsheetApp.getActiveSpreadsheet() );
});
Happy to share a spreadsheet with more code in it.