Pretty much everyone on our team has been complaining about .iml files constantly showing changes even though they haven’t changed anything in the build.
Today we performed an experiment. One person confirms that everything is clean in their project and checks in all the .iml files. Another person then updates, runs
gradle idea and then looks for differences. If something has changed, then
gradle idea is the culprit, otherwise it is some other thing (it could have been IDEA itself.)
It turns out that
gradle idea is indeed the culprit. What I’m seeing here appears to be some kind of random (or at least, I can’t see the pattern) shuffling of the contents of the .iml file.
Typically, this sort of issue means that somebody thought it was a good idea to use
HashMap instead of
LinkedHashMap (which maintains insertion order) or
TreeMap (which sorts), and indeed, if I do search through Gradle’s source repo, I do see usages of
HashMap. For example:
So seemingly the order you get things will depend on which order the modules happened to be for each person, and I can see that in the same .iml files, the list of
ModuleDependency varies from person to person.
I figure I can probably do hack something together in a
whenMerged callback to dodge this issue, programmatically re-sorting dependencies back into some kind of stable order, but it isn’t going to be easy because the plugin has added all the libraries as raw jar files. Had it at least used project libraries, the name of the library would have provided a convenient key to sort by.
So I have gathered two issues here:
- The order itself shouldn’t matter (though it can, in extreme situations), but it should at least be stable, and isn’t.
- It would be nice if project libraries were inserted into the project as project libraries, if only to cause less bleeding to the eyes when you do go into the project structure to have a look. (It would be even better if it would insert them as proper Maven dependencies so that IDEA could pick up the changes and auto-download them.)
Why do we still check in our .iml files? Because there is another issue (considered a feature, supposedly) where Gradle will successfully create incorrect .iml files when things go wrong. Being able to revert to working project files allowed us to continue to work a few times now, so we’ll continue to use the checked-in .iml files as an escape hatch until we can trust the tool.