I've been having a look on how to get existing projects to use the Dotty compiler.
This has been straightforward for small projects following this.
https://github.com/lampepfl/dotty-example-project
This sets the scala version to 0.2.x. Which would mean that SBT could not find all the dependant libraries. However this can be sorted out by using withDottyCompat. This tells sbt to just go and get a 2.11 version. eg
eg ("org.scalatestplus.play" %% "scalatestplus-play" % "2.0.0").withDottyCompat()
All good so far. Where I'm stuck is to tell sbt to get play 2.11 versions of all the dependancies of a sbt plugin. Particularly Play! Eg
"com.typesafe.play" %% "twirl-api" % "1.1.1"
I can't work out how to intercept this and ask sbt to download the 2.11 version of the play dependencies.
Anyone managed this?
Related
i know that it exist cross-build options to generate various version of a scala API running with different scala version. Let's say i will stay with the same scala version 2.11.12, how can i set my build.sbt to handle multiple version of spark. I have some hint about the "provided" option for dependencies but i'm not sure it is the best way to handle it.
Bonus: what if some spark version are using 2.11 and others 2.12...
Please let us know if you've already ridden through this issue.
"org.apache.spark" %% "spark-core" % "2.3.2"
Use the double % -sign when defining dependencies, sbt then will handle the scala version for you. You should use the same scala version for all your dependencies.
I have created a libs folder and placed scalascriptengine-1.3.9-2.11.0.jar in there. After that, I right-clicked on the .jar and selected Add Library.
Then, I created Test.scala:
import java.io.File
import com.googlecode.scalascriptengine.ScalaScriptEngine
object Test {
def main(args: Array[String]): Unit = {
val sourceDir = new File("examples/folder")
val sse = ScalaScriptEngine.onChangeRefresh(sourceDir)
}
}
It correctly recognized ScalaScriptEngine, or at least it did not give any warnings or errors. But it did not compile.
According to the library page I edited my build.sbt:
name := "ScalaScriptEngineTest"
version := "1.0"
libraryDependencies += "com.googlecode.scalascriptengine" %% "scalascriptengine" % "1.3.10"
libraryDependencies += "org.scala-lang" % "scala-compiler" % "2.11.1"
But upon refreshing, I get this: http://pastebin.com/GdirttUJ
What am I missing? I am learning scala and it is the first time I am trying to add a library to IntelliJ Idea...
Short answer:
Change the two dependency entries in your build.sbt as follows:
libraryDependencies +=
"com.googlecode.scalascriptengine" % "scalascriptengine" % "1.3.9-2.10.3"
libraryDependencies += "org.scala-lang" % "scala-compiler" % "2.10.4"
Notice I didn't just change the versions -- I replaced your %% with a single %.
This results in you using a slightly older version of ScalaScriptEngine, and I don't know if that will cause any problems for you.
If you're using sbt build dependencies you don't need to be manually placing jars anywhere.
Explanation:
From your log I see that sbt is looking for the ScalaScriptEngine for Scala 2.10. In fact, it's pretty clear that you're running Scala 2.10.4, even though your sbt file expresses a dependency on the 2.11 compiler, which in fact is consistent with the instructions for using ScalaScriptEngine.
On line 23 of the log you can see exactly where it's looking. If you point your browser part way down that path you'll see that there is a version for Scala 2.11 and another directory, scalascriptengine, without a version qualifier. If you dive down the latter, you'll see it's where they keep all the old versions. There isn't a ScalaScriptEngine 1.3.10 (the one you asked for) compiled for Scala 2.10, so your options seem to be to upgrade to Scala 2.11 (which I don't think currently works if you want to use IntelliJ Idea's tight integration with sbt), or you can use ScalaScriptEngine 1.3.9.
You have basically the same problem with your Scala compiler dependency -- it needs the be the Scala version you're using.
I've confirmed the above solution with Scala 2.10.4. I'm playing it a little fast and loose because there isn't a pre compiled version for 2.10.4, and I gambled that the 2.10.3 build will probably work.
Alternatives:
There may be a cleaner way to solve this, but the way the repository is organized makes me doubt it.
You could build the version of your choice with the compiler of your choice, or persuade the ScalaScriptEngine community to do it for you and put it in The Central Repository, but my guess is that 1.3.10 won't build with anything lower than Scala 2.11.
Finally, if you do want to download jars by hand, you may want to read the "Unmanaged dependencies" section of the sbt documentation. Actually, if you're going to use sbt, just read the whole thing a few times.
Suppose I've got a SBT 0.13 project that's cross-built against Scala 2.9.3 and 2.10.4. I want to use an SBT plugin (sbt-coveralls) for the 2.10 build only, because the plugin isn't available for 2.9.
I know that I could use CrossVersion to conditionally add the plugin settings to the 2.10 build, but that doesn't help with the fact that addSbtPlugin isn't going to find anything for the 2.9 build, etc.
I'm assuming this is impossible (short of some really messy ad-hoc shell scripting) but I'm not an SBT wizard, and it would be nice to be surprised by the mysteries of SBT in a good way for once.
Found this horrible hack of a workaround, but it does seem to work:
resolvers <++= scalaVersion {
case v if v startsWith( "2.12" ) =>
Seq.empty
case _ =>
addSbtPlugin( "org.scoverage" % "sbt-scoverage" % "1.0.4" )
addSbtPlugin( "org.scoverage" % "sbt-coveralls" % "1.0.0" )
Seq( Classpaths.sbtPluginReleases )
}
I might misunderstand the question, but I think you may be confused with sbt's vs a project's versions of Scala.
You cannot use a plugin that's incompatible with sbt - the runtime. If a plugin doesn't support the version of Scala sbt uses under the covers the plugin is deemed incompatible and hence sbt will refuse starting up. sbt 0.13.5 uses 2.10.4 so the plugins can only use Scala API 2.10.4. That's why addSbtPlugin offers no %%.
For projects, it's different. Here you could use whatever version you want regardless of the version sbt uses and hence the plugins. Once you've addSbtPlugin'ed a plugin, the plugin's available in a project, and to enable it, add the settings to projects.
I want to add a Java library (e.g. Apache PDFBox) to an sbt project.
This is the Ivy dependency:
dependency org="org.apache.pdfbox" name="pdfbox" rev="1.8.2"
I first tried to do the following:
resolvers += "Sonatype releases" at "http://oss.sonatype.org/content/repositories/releases/"
libraryDependencies += "org.apache.pdfbox" %% "pdfbox" % "1.8.2"
But it gives me errors of the type
[warn] ==== public: tried [warn]
http://repo1.maven.org/maven2/org/apache/pdfbox/pdfbox_2.10/1.8.2/pdfbox_2.10-1.8.2.pom
So I understand that with this syntax I can just manage Scala dependencies. I am sure that there is a way to manage Java dependencies, but how?
I tried to search in Google for "sbt add java dependencies" but did not find (recognize) a relevant result.
You should replace the %% (double percent) with single one.
libraryDependencies += "org.apache.pdfbox" % "pdfbox" % "1.8.2"
The double-percent is a convenience operator, and causes adding the _+scalaVersion postfix inside the path, which is _2.10 in your case. Single percent should fix the problem.
Short answer:
Use
libraryDependencies += "org.apache.pdfbox" % "pdfbox" % "1.8.2"
For java libraries, and
libraryDependencies += "org.scalactic" %% "scalactic" % "3.0.8"
For Scala libraries, where the difference is the double % for the scala library.
Long answer:
Scala is not backward compatible across major version, so a library compiled for scala 2.12.x cannot be used by a project written in scala 2.13.x.
So when writing a scala library, you will need to compile and publish it one time per scala major version you would like to support. When using a library in a project, you would then have to pick the version compiled for the same Scala major version as your are using. Doing this manually would be cumbersome, so SBT has built in support for it.
When publishing a library, you can add the crossScalaVersions key to SBT like
crossScalaVersions := Seq( "2.10.6", "2.11.11", "2.12.3" )
And then publish with sbt +publish. This will make SBT build and publish a version of the library for both scala 2.10.6, 2.11.11 and 2.12.3. Note that the minor number is in-relevant, when it comes to compatibility for libraries. The published libraries, will have the name suffixed with _2.10, _2.11 and _2.12 to show what scala version it is for. An alternative to using the SBT build in support for this, is to use the experimental plugin sbt-projectmatrix as this gives a lot more options, and often faster builds.
When using a library sbt can also help your use the one compiled for the correct scala version, and thats where %% comes into play. When specifying a library without the _ suffix in the name, but instead use %%, then sbt will fill in suffix matching the Scala major version your use, and thereby fetch the correct version of the library.
I follow these steps to configure a project for IntelliJ idea.
addSbtPlugin("com.github.mpeltonen" % "sbt-idea" % "1.2.0")
I use sbt-idea for sbt version 0.12 with fixed bug for Idea.
When I type sbt in my project's directory, I noticed that it uses scala 2.9.2.. but I'm going to use scala 2.10.1 for my project.
Questions:
Does it make sense which scala version to use for plugin(s) (~/.sbt/plugins)-compilation, or I should use one/same scala version for everything? Can I change scala version for plugins?
So, I created ~/.sbt/plugin/build.sbt file with mentioned content.
that version is out of date, it depends on sbt-idea 1.2.0-SNAPSHOT. The latest at the time of writing is 1.3.0
See my project skeleton for an implementation using the latest versions of scala, scalatest and SBT to IDE project plugins.
Actually I got it.
if you have a project with build.sbt (that uses 2.10.1 scala) file - as soon as you type sbt.. all dependencies will be downloaded into ~/.sbt folder - even scala compiler will be downloaded there (~/.sbt/boot). It could be even several version of scala: 2.10.1 and 2.9.2 for example.
and about sbt-idea and ~/sbt/plugins .. it could any scala version - depending on its build.sbt file, for example in my case:
resolvers += "Sonatype snapshots" at
"http://oss.sonatype.org/content/repositories/snapshots/"
addSbtPlugin("com.github.mpeltonen" % "sbt-idea" % "1.2.0-SNAPSHOT")
I should notice if try different version.. like 1.1.0-M2-TYPESAFE it will not work.. (at least in my case) - gen-idea command is not available then. I do not know why. I guess it should.
Also if you do not point resolvers += - it will will not work.. but it it will not tell you about that..
This plugin is using scala 2.9.2 - we can not see it here, but we can see it from that outputs it produces while installing/downloading. That's why we have ~/.sbt/boot/scala-2.9.2/ as a result.
In any case we should not care about it. It is handled by sbt.
When you converted your sbt-project into your intellij-idea project by typing gen-idea in sbt console, as the result your IDE project will be referencing to ~/.sbt/scala but not to your somewhere-installed-scala.. So even no need to pointing the scala location - that sbt-idea sbt's plugin will do all the work. And that's good!
That's the answer I wanted to get. One gets/understands it by trying it.