An alternative would be to add an extension that allows to set the Scala version (e.g. {{scala

}}), and if set, add the appropriate scala-compiler and scala-library dependencies to the scalaTools and compile configuration, respectively. (The decision whether to automatically add these dependencies could also be based on another property, say scala.addScalaJars=true/false.) Not sure which approach I like better (extension or inferring). The extension approach would also make sense for Groovy.

The extension approach doesn't work well when you want to build multiple variants. We should infer the Scala version for each ScalaCompile task from its compile classpath. As a first step, we can approximate the compile classpath using configurations.compile. Later, we can add a way to inspect the classpath attached to each task.

If we want this to work with variants, then I suggest that the task itself configures its `scalaClasspath` based on its `classpath` whenever the former is empty. Or maybe the plugin should do that. But I wonder if that's better than doing it right in the task, and it's less clear how to implement it well (convention mapping etc.).

Another way to make this work with variants is to (eventually) allow multiple Scala versions to be specified.

Here is what I have, implemented in the Scala plugin:

If ScalaCompile.scalaClasspath isn't set, and configurations.scalaTools is empty, then sniff Scala library version from ScalaCompile.classpath, and set ScalaCompile.scalaClasspath to a detached configuration containing the Scala compiler dependency with the same version. Alternatively, we could configure configurations.scalaTools based on sniffing from configurations.compile, but that is less accurate/versatile (won't work with multiple source sets or variants).

Another question is how to do the version sniffing. If we sniff the version from ScalaCompile.classpath (which is a FileCollection), the only option is to search for a "scala-library" filename. If we sniff it from configurations.compile, we can alternatively search for a "org.scala-lang:scala-library" dependency. Not sure if the differences matter in practice.

We should do the same for the Groovy plugin. This will solve the nasty "but I only want Groovy on the testCompile class path" problem (and similar ones).

Absolutely we should. Can you pick up GRADLE-1124 after this one?