We have discussed adding the Scala container before. The downside of adding the container is that we can no longer enforce that Gradle build and IDE use the same Scala version. On the other hand, if we add the Scala Jars used by the Gradle build (as we do now), we cannot guarantee that the IDE works with them (it might only support a different Scala version). Which do you think is the lesser evil?

There are actually two separate issue covered by this bug report / enhancement request:

1: Out of date package names for the Scala nature and Scala builder items in .project. Hopefully there is no question about this area. I have verified that the old ("ch.epfl.lamp...") package names that are currently put out cause a problem with the newer Scala IDE, and the new package names ("org.scala-ide...") don't.

2: Should running the "eclipse" task when the Gradle "scala" plugin is enabled, also add the Scala container ("org.scala-ide.sdt.launching.SCALA_CONTAINER") in .classpath?

I had thought this was the best idea, because then you would automatically (in Eclipse) pick up the same matching version of the Scala libs (scala-library.jar, scala-dbc.jkar, and scala-swing that jar) that the Scala IDE Plugin itself was built against. But you do raise a good question: what happens if the command-line build via Gradle is not via the same version. And it's actually even worse than that, because when I experimented and manually added the Scala container, I realized (and sorry, should have seen this before) that you then end up with two copies of the Scala libs (with potentially different versions), in Eclipse, those added via the Scala container, and those added as regular classpath entries in .classpath by Gradle.

So for the time being, it seems to make the most sense to leave the container out. I have verified that as long as you are careful to match the same version of Scala in the Gradel dependency declaration that the Scala IDE plugin itself is expecting, it all still works. i.e. running "gradle eclipse" adds the classpath entries for that version of the libs, and the Scala IDE Plugin still seems to be happy. I tried using an older version of the libs, and the plugin threw up some error and offered to add the Scala libs itself (i.e. add the container) at that point. So while it's not the clearest error, there is some indication of a mismatch if you goof things up.

I am a total Gradle newbie, but the other thing that would also work if it can be done, is for the Scala container to be added, but the Scala libs that are used at command line to not be added to .classpath (since they are coming in via the container). That would eliminate any chance of mismatch of Scala versions in Eclipse, but it doesn't answer the question of what happens if the command line build uses a different version. For the time being, not adding the Scala container still seems the lesser evil to me.

I've updated the nature and builder IDs as requested. We'll decide separately whether to add a container for the Scala libraries.