[GRADLE-1470] Scala Eclipse metadata put out via Eclipse+Scala plugins is outdated Created: 12/Apr/11 Updated: 04/Jan/13 Resolved: 01/May/11
|Reporter:||Colin Sampaleanu||Assignee:||Peter Niederwieser|
Some months ago work on the "official" Scala plugin for Eclipse was taken over by the main Scala group (Martin Odersky & company), and the home for the plugin moved to http://www.scala-ide.org/. As part of this, packages for the plugin changed to "org.scala-ide..." from "ch.epfl.lamp.sdt...".
When using the eclipse & scala plugins, doing a "gradle eclipse" still puts the old package names in the .project and .classpath files that are generated. Additionally, only the Java container is set up in .classpath, when it should also be setting up the Scala container.
The plugins need to be updated to reflect the new package names which are already being used (see here: http://download.scala-ide.org/), and to add the Scala container.
Currently, the plugins generate in .project:
The plugins currently generate in .classpath:
This will then mostly match projects that are set up by using the "New Scala Project" wizard provided by the Scala IDE plugin itself. I say mostly because the Java container looks to be a bit more tweaked when I actually use the wizard:
|Comment by Peter Niederwieser [ 26/Apr/11 ]|
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?
|Comment by Colin Sampaleanu [ 26/Apr/11 ]|
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.
|Comment by Colin Sampaleanu [ 26/Apr/11 ]|
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.
|Comment by Peter Niederwieser [ 01/May/11 ]|
I've updated the nature and builder IDs as requested. We'll decide separately whether to add a container for the Scala libraries.