From an email from Adam:

1. The tooling api filters out the extra tasks when building the model. But only if the eclipse plugin was not applied in the build.

2. Split an eclipse-model plugin out of the eclipse plugin. The eclipse-model plugin adds and configures the model. The eclipse plugin adds the appropriate tasks as the bits of the model are made available. The tooling api applies the eclipse-model plugin, rather than the eclipse plugin.

3. The tooling api applies the eclipse plugin when running a build, not just when building the model.

4. A task rule automatically applies the eclipse plugin when one of its tasks are referenced, whether from the tooling api or the command-line. There's been a few feature requests for this kind of thing, for the IDE plugins and the wrapper.

I'd say 3. is the way to go, but I'd really like 4. as well.

Is there any use case where people want to be able to use the Eclipse tasks of Gradle when they are working with the Gradle Eclipse plugin. Specially if they haven't applied it.

4.) is something we really need in any case. Also for any archetype plugins for example. It would be an important generic feature. I still think it is not the best solution for this issue, as the noise (eclipse task are displayed) are still produced. Unless I'm missing something and displaying the eclipse tasks does actually makes sense. So even with 4.) I think there is a point for 1.) and 2.).

1.) and 3.) look like the easiest fixes for avoiding the actual bug. But as said, I don't like the side effect of 3.).

I have no idea why someone who uses the STS would like to run the eclipse tasks.

Out of the options above, I'd go for #3 because it feels extremely cheap to fix.

At the end of the day option #1 was simplest to implement.