Is there any way to use scala-pickling with scala 2.11 yet?
I've tried the only scala-pickling_2.11 artifact at the sonatype repository but it doesn't seem to work. I get the message:
Error:(26, 43) can't expand macros compiled by previous versions of Scala
I think you can't use scala-pickling with higher versions of scala but there is boopickle which might help you out.
You can easily import it into an sbt project with
libraryDependencies += "io.suzaku" %% "boopickle" % "1.3.2"
and this works with scala version 2.13.3 at least.
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'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?
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 am cross building a scala project with sbt 12.1.
crossScalaVersions := Seq("2.9.2", "2.10.0")
However, it can't find the dependencies because they are named _2.10 not _2.10.0. It seems like it's regular to name your library 2.10 instead of 2.10.0 with the exception of scala-language and scala-compiler. For example, scalaz is not found at http://repo1.maven.org/maven2/org/scalaz/scalaz-core_2.10.0/6.0.4/scalaz-core_2.10.0-6.0.4.pom but at http://repo1.maven.org/maven2/org/scalaz/scalaz-core_2.10/6.0.4/scalaz-core_2.10-6.0.4.pom.
Is there an easy way to handle this without writing custom rules for all of my dependencies?
The actual build.sbt is available online.
Since 2.10.x releases are binary compatible between each other, libraries need to be built only with one version of scala library - and they can (and must) drop the .0 part (if you publish with sbt, it is done automatically). When the maintainer of a library releases a library with _2.10.0 tag, it's a mistake and you should consider filing a bug.
By the way, I looked on your build.sbt - running +compile on it works for me (sbt 0.12.1). Do you experience some errors?
To get the Scala version incorporated into the artifact name in the Scala way, you specify the dependency with the %% operator:
libraryDependencies += "io.backchat.jerkson" %% "jerkson" % "0.7.0"
When the exact match is not available, you can specify the Scala version explicitly (but remember compatibility only exists across patch releases of a given major/minor release of Scala):
libraryDependencies += "io.backchat.jerkson" % "jerkson_2.9.2" % "0.7.0"