Gradle IDEA plugin appears to shuffle the modules and libraries

Old Forum Archive Bugs
1

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:

  1. The order itself shouldn’t matter (though it can, in extreme situations), but it should at least be stable, and isn’t.
  2. 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.

2 Likes
2

Reported before as:

No tracking JIRA as of now.

3

Both of those issues appear to indicate that it’s reordering the dependencies in some stable way, but what I’m seeing is more like random insertion of one or two dependencies completely in the wrong position in the list, versus what another user on the same project sees when they run the exact same command.

Is it really the same issue?

1 Like
4

Indeed, it is a separate issue, still both can be addressed by the same fix.

5

I guess that’s true, but I don’t particularly care whether it reorders the dependencies, as long as it does it the same way every time, irrespective of the phase of the moon. So the minimum fix for my issue is probably quite a bit simpler than whatever the proper fix would involve.