Eclipse plugin derails Gradle nature

Using Eclipse Juno with the Gradle plugin active (which comes with Gradle 1.2).

Steps to reproduce: Run As… Gradle Build… Activate cleanEclipse and eclipse

Eclipse is somewhat confused about the state of the Gradle nature after that: - The Gradle icon vanishes - The context menu still contains the Gradle submenu - The entries in the submenu are all still enabled, but clicking any of them will just complain that it is disabled - After that, the Gradle submenu still exists but all entries are in fact disabled - You can Configure->Enable Gradle Nature

Workaround: Configure->Enable Gradle Nature reactivates all the gradle features for the project.

I have the same problem and I have latest release version of everything. That would be nice if someone start to work on it.

Why do you explicitly run the ‘eclipse/cleanEclipse’ tasks when using the Eclipse Gradle tooling?

For the same reason there’s a cleanEclipse goal in the first place: To reset the project to a known clean state after it got changed by the developer or some other plugin, just to be sure that everything is back to what build.gradle specifies. I regularly do Gradle run… with a target list of cleanEclipse,eclipse. (The eclipse target tries to leave settings intact, which is not what I want after the project configuration got mucked up.)

It’s also a kind of nonassociativity. A single gradle run with two targets is normally equivalent to two runs with a single target each. With cleanEclipse,eclipse it is not so, cleanEclipse kills the project configuration and I can’t start the eclipse target anymore. (Talking about running gradle from inside Eclipse, of course. I could always fire up the command line and do gradle eclipse, of course. I’m finding it easier to simply re-add the Gradle nature though, so a workaround exists; it’s more a problem for the newbie who is suprised by the removal of the Gradle nature.)

I think cleanEclipse should simply leave the Gradle nature in. If the Gradle nature has attributes, maybe these should be reset - that might be easiest to do by removing the Gradle nature and re-add it.

Running ‘cleanEclipse eclipse’ won’t set back the state when using the Eclipse Gradle tooling. It’s not meant to be used in this way. ‘cleanEclipse’ deletes all Eclipse files, and it can’t leave something in.

I find using them in conjunction very useful. The plugin gives me Run As… -> Gradle and bundling all the Gradle-induced dependencies in their own subcategory in Project View. cleanEclipse gives me the ability to reset the project’s state back to what Gradle expects, all the inadvertent or experiment-induced changes in the project settings are then gone. Experimenting with the project is very useful - sometimes I don’t know exactly what setting Eclipse needs to change someting so I muck around in the Eclipse configuration until I get what I want, then I modify my build.gradle to make it configure Eclipse to that state. This approach has been working great for me, and decomposed the “I need to find out how to configure Gradle to get an Eclipse change that does to the build what I want” into two smaller, more easily tested and checked tasks.

So while the two aren’t intended to be used together, I found a use case where they still do :slight_smile: Note that I’m not using STS, I installed the Gradle plugin into an existing Eclipse setup.