After importing Gradle projects, I find org.eclipse.jdt.groovy.core.prefs in any prj

[mauromol]

Hi,
I have the following situation.
Consider a Gradle multiproject checked out from SVN.
This Gradle multiproject is set up for the use with STS 2.9.x.
Then, I import this multiproject in my new workspace using the "Import | Gradle project" wizard of STS 3.1.0.
In the import wizard dialog, I ONLY check "Enable dependency management", nothing else. Then I choose to import the whole Gradle multiproject.

After the import operation has finished, I find that the legacy STS projects are converted to 3.x format (that is: some com.springsource.* preferences are renamed to org.springsource.*). So far so good.
The strange thing is that a new file (org.eclipse.jdt.groovy.core.prefs placed in .settings folder) is added to ALL the Eclipse projects. This happens also for Java projects that DO NOT have the Groovy nature. I already checked that for those project:
- Groovy nature is missing
- Groovy libraries are not in the build path
- Gradle DSL support is disabled
So, why do I find those files in those projects? The contents of those files is just: eclipse.preferences.version=1 and groovy.compiler.level=18.

Who is responsible of the creation of those files? Is it Greclipse? If so, how is it possible, considering that the Groovy nature is missing on those projects? Is Greclipse in some way "enabled" on those projects all the same?

Thanks in advance,
Mauro.

[Kris De Volder]

These settings come from Groovy eclipse.

> If so, how is it possible, considering that the Groovy nature is missing on those projects?

Good question. I don't know. And I think they shouldn't be added.
I think Andrew may know more about this. I'll ask him to comment.

[Andrew Eisenberg]

You've probably already figured out that this setting can be safely ignored and that greclipse is not enabled on the project (requires the nature to be added for that). So, this setting is essentially a no-op.

Now, I am not exactly sure why this setting is being added. All places in the code where the setting is added to a project, the project must have a groovy nature. But, once the setting is added, it is not explicitly removed when the groovy nature is removed.

So my guess is that these project somehow temporarily (erroneously?) are given the groovy nature, the setting is added. Then the nature is removed, but the setting is not.

I have not been able to reproduce this yet, but I will try with some gradle projects. If you could share with me a project where this happens reliably, that would be great.

[Kris De Volder]

> So my guess is that these project somehow temporarily (erroneously?) are given the groovy nature, the setting is added. Then
> the nature is removed, but the setting is not.

So in that case, maybe its the Gradle import wizards fault... I don't think it adds Groovy nature unless 'DSL support' is enable but maybe I'm wrong about that. I'll see if I can reproduce.

Kris

[Kris De Volder]

Well... I tried importing a very simple Gradle project (i.e. the Java quickstart sample from the gradle distribution)...

Disabled everything except 'dependency management' and it doesn't add jdt.groovy prefs.
So I can't really reproduce.

Are you sure the settings file was not already there before importing?

If the project at any time had a groovy nature it is likely that it got added and I think running the 'cleanEclipse' task does not wipe the .settings folder.... so it would probably stay put unless you manually deleted it yourself.

[mauromol]

Well, I'm sure the file was not there already because the imported project was shared with SVN and after import I saw all those Groovy prefs files marked as "new" (added).
What might be different in my use case is that the conversion from the legacy STS project format has been performed while importing (in other words: projects before import were in the old STS 2.9.x format, after import they were in the STS 3.x format).

[Kris De Volder]

That could be the difference. It still is mysterious since I cannot imagine how the migration from 2.9 to 3.0 would add these settings files. If I get some time I will try and create a simple 2.9 project to play with a bit.

To get an idea of the seriousness of the issue... Is this a one-off thing? I.e. if you remove the settings after the projects have been migrated and re-import them... does the problem repeat itself or do the settings file stay gone?

Kris