The contents of this blog post have been superseded by the most recent nightly. Go there for the latest documentation.
We are thinking of uniting the development of the Scala IDE to just a scala 2.11 branch, while still supporting 2.10 projects. For that, we need rock-solid support for 2.10, and you can make a difference. This blog post is here to give you news about the development — up to the latest nightly — and enlist your contributions in reporting possible problems or errors. More details on how to contribute below.
As you may have heard, the latest milestone of the Scala IDE comes with the ability to interpret both 2.10 and 2.11 projects. In the latest nightly, it’s now much better.
The executive summary is this: the IDE still comes built on and embedded with a single version of the Scala compiler (the latest 2.11). It runs it to access your code for all interactive functions (typechecking, etc). But that presentation compiler now has the ability to run in “2.10 compatibility” mode, interpreting your types and terms with the logic that was valid in the legacy version of Scala.
For non-interactive functions (i.e. building), the compiler will send your code to a regular, unmodified 2.10 compiler that we ship along the IDE.
So, when using the IDE, your 2.10 projects shouldn’t change. In particular, their classpath should be that of a regular 2.10 project — that is, they should have the 2.10 scala-library on classpath. So goes for other jars and libraries you might use, whether 2.10 projects like play or other compiler-associated jars, like scala-swing.
Projects created with the Scala IDE, or with sbteclipse, set the path to the scala-library using a classpath container, an abstraction designed to help with managing machine-scpecific paths towards a set of jars. These classpath containers (one for the lirbary, one for the compiler), in particular, represent the technical notion behind what Eclipse calls User Libraries.
These containers, in the latest milestone, always pointed to the
default version of Scala (2.11). To use an IDE-created project
with Scala 2.10, you had to get rid of the classpath container,
and replace it with your own jars in the Java Build Path
menu. Or you could use sbteclipse with the
withBundledScalaContainers := false
option to generate an
Eclipse project which would explicitly link to sbt-provided scala
2.10 libraries.
With the latest nightly (as of July 4th), you now have the freedom of configuring the content of the Scala classpath containers.
The first user-visible change is that the switch between the 2.10 and 2.11 modes is now a clearer, more visible toggle at the project-specific compiler options level.
A dialog will still pop up if your classpath suggests your project may be configured to run on 2.10, and it has the same effect as setting the toggle to 2.10 above.
The default for the whole workspace-wide IDE plug-in is still to run on 2.11 so that you will for now have to make this setting per-project.
If you now head to the workspace-wide preferences (Window → Preferences on Windows/Linux, or Eclipse → Preferences on OSX), you can see under the Scala heading an Installed Scalas window which lists the Scala versions you can use.
Those translate directly to your classpath containers, that is setting the source level toggle selects the corresponding scala installation for your project.
To witness that, you can have a look at your project’s classpath (Java Build Path in your project’s Properties). Or you can unfold your project’s details in the Package Explorer. You’ll see this for a 2.10 project:
You also have the option of editing that container (right-click → Properties in the Package explorer, double-click or Edit in the Java Build Path window). You can the choose amongst the installed Scala versions
Beware, that edition does not affect your source-level flag in and of itself, though consistency checks may pop up a dialog suggesting you to set the source level according to what you just put in the container.
We are evaluating the possibility of dropping 2.10 builds of the Scala IDE, which would save us the time and effort spent maintaining them, as well as let us enjoy the gains brought by the latest scala version. We’d be able to deliver IDE features much faster ! But this can only be done if this multi-version support is reliable. For this, we need testing. Have any 2.10 projects you want to work on ? Install the latest nightly, use the 2.10 support, and tell us about any problems you encounter !
The source level toggle in compiler settings does not give
immediate feedback on the “Additional parameters” line of
compiler options, even if it adds -Xsource:2.10
-Ymacro-expand:none
to it. If you save, close the compiler
options dialog and reopen it, you should see those compiler
options added explicitly.
There is currently no option to define a custom scala installation, and use it to configure the classpath container of your projects. We are actively working on this.
The previous limitations of the multiple-scala-version support still apply.