Assume you have a Gradle multiproject and that it is under version control.
Suppose this project is already an Eclipse project and all the Eclipse metadata files (.project, .classpath, .settings folder, etc.) are under version control.
You check it out in a folder and then use the STS Gradle Import Wizard to import in a new repository.
Suppose you UNCHECK all the following: run before, run after and create resource filters.
You do that because you know that all the necessary data are already there, because the whole thing is under version control: so, you just want to "mount" the main project and all the subprojects into the workspace. (note: ideally, you may use the standard Import Existing Project into workspace, but you can't because the main project, which is at the root of the Gradle multiproject, is hiding the subprojects).
After the import process has finished, even if you chose not to do anything special, you'll see some outgoing changes in the workspace:
.settings/com.springsource.sts.gradle.core.prefs for all the subprojects: see
.settings/com.springsource.sts.gradle.core.import.prefs of the main project: see
.classpath of the main project: the order of the classpath entries related to the subprojects is not predictable
I mean, repeating the project import over time shows that the <classpathentry>s in the .classpath file are changed every time: the content is the same, but the order of the different entries can change.
Why the import wizard changes that file if I unchecked the execution of all the Eclipse Gradle plugin tasks? I would expect the wizard to just "mount" the projects, without touching the .classpath of the main project. This would be the best way to solve this problem, because if the .classpath is there (and is under version control), I assume I want it to be like that.
If changing is unavoidable, at least please make the import wizard generate those <classpathentry>s in a predictable order: they may reflect the order in which dependencies are declared in the Gradle build script or, at least, some other sorting criteria (alphabetical on the subprojects name, for instance).