How to add ScalaScriptEngine library in IntelliJ Idea - scala

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.

Related

Why Scala's-SBT is too slow

I am facing slowness at many places while working with sbt
Importing SBT Project in Intellij -- approx(8-10 minutes).
Indexing in Intellij of SBT Project.
sbt (In terminal this command takes -- approx(2-3 minutes)).
compile (In sbt shell this command takes -- approx(3-5 minutes)).
5.Whenever I modify build.sbt file then project refresh takes 3-4
minutes.
There are more places i need to check but above specified points i am facing frequently.
Is this problem related to SBT or Scala ?, If yes How to resolve the same
Note : I have good internet connection so this cannot be network issue.
My Scala Class file :
import org.scalatest._
class TaskManagerSpec extends FlatSpec with Matchers {
"An empty tasks list" should "have 0 tasks due today" in {
val tasksDueToday = TaskManager.allTasksDueToday(List())
tasksDueToday should have length 0
}
}
build.sbt
name := "tasky"
version := "0.1.0"
scalaVersion := "2.11.6"
resolvers += "Artima Maven Repository" at "http://repo.artima.com/releases"
libraryDependencies += "org.scalatest" %% "scalatest" % "3.0.0" % "test"
SBT is slow because compiles internal code that is done in Scala and Scala compilation is slow because is a complex language (but once Scala is compiled is a lot faster at runtime)
You can give SBT a boost when using SBT 1.x version with the SBT server. The SBT server allows you to use just one SBT instance shared between command line and the IDE. This is pretty useful, more info here: https://www.scala-sbt.org/1.x/docs/sbt-server.html
Also considere using other build tools that are lighter, like PANTS, that is based on Python which is interpreted and a lot faster. More info at: https://www.pantsbuild.org/
NOTE: the PANTS documentation and community is not as extensive as with SBT but is worth the try, there are amazing things that can be done with PANTS.
NOTE2: if your code base is large it will still take a lot of time to compile/build, so considere to arrange your code and artifacts as incremental/cached pieces/subprojects to see a real boost.

How to handle versions of sbt, scala, libraries

When playing with something in Scala, I typically spend a bunch of time trying combinations of dependency versions, Scala versions, %% vs %, etc. And when it starts working, I am not quite sure why, or for how long...
It would be great if someone could explain the Scala ecosystem's way(s) of dealing with versions of sbt, scala, and libraries. Or perhaps point me to some documentation.
I struggled with this extensively when i started out. These days i start every project with a boiler-plate build.sbt with just scalaVersion and whatever sbt is currently on my machine:
organization := "foo"
version := "0.1"
scalaVersion := "2.10.4"
Pick the latest 2.10 or 2.11, dependening on your need. Most libraries of note are cross-published into both.
Now, as you find libraries you want to use, head over to http://mvnrepository.com/ and search for them there. Look for a _2.10 or _2.11 postfix (depending on your version). If it has neither, you are likely fine.
Once you find your library and the version you want, mavenrepository even provides you the sbt link you need to use in its sbt tab like this:
libraryDependencies += "com.typesafe.play" % "play-test_2.10" % "2.4.0-M3"
And from there you can even explore the dependencies that library will bring along with it. This should cover most of your day to day needs.

Future-proofing a Scala/SBT project

I am trying to use scala-graph and scala-swing in the same program. I can use the latest graph-core library (1.9.2) alone with the latest version of scala (2.11.6). I can use scala-swing, but when I do that, sbt gives me Scala 2.10.4 rather than 2.11.6.
When I tried to use both libraries, I got errors -- either compilation or runtime errors, depending on how I set up build.sbt. So I tried using an older version of graph-core (1.8.0), which if I understand the library's release history [1] correctly, was designed for Scala 2.10.
Doing that works, although it causes sbt to use scala 2.10.4 instead of 2.11.6. I'm worried because it seems like a fragile arrangement.
Will it keep working? Currently my build.sbt file (below) does not restrict the scalaVersion or the scala-compiler version; it just says which graph and swing libraries to use. I'm afraid that changes to the graph library, or the swing library, or the scala language itself, will break the code.
[The rest of this post describes my OS, installations, and code; you might not need to read it.]
I am using Ubuntu 14.04. I installed scala and sbt using apt-get. swing appears already to be installed on my machine. I did not install the graph library but sbt seems to take care of it.
My only two files are in the same folder: build.sbt and main.scala. The build.sbt looks like this:
lazy val root = (project in file(".")).
settings(
name := "main",
version := "1.0",
libraryDependencies += "org.scala-lang" % "scala-swing" % "2.10.5",
libraryDependencies += "com.assembla.scala-incubator" %% "graph-core" % "1.8.0"
)
main.scala looks like this:
import scalax.collection.Graph // or scalax.collection.mutable.Graph
import scalax.collection.GraphPredef._, scalax.collection.GraphEdge._
import scala.swing._, scala.swing.event._
object App extends SimpleSwingApplication {
def top = new MainFrame {
val g1 = Graph(3~1, 5) // no effect; just tests the constructor
val button = new Button { text = "Click me" }
contents = new BoxPanel(Orientation.Vertical) {
contents += button
border = Swing.EmptyBorder(30, 30, 10, 30)
}
}
}
Thanks.
[1] http://www.scala-graph.org/download/
First, you need to use "org.scala-lang.modules" %% "scala-swing" % "1.0.1" for 2.11.
I'm afraid that changes to the graph library, or the swing library, or the scala language itself, will break the code.
Since you have specific fixed versions of both libraries, release of new versions can't affect it; but I certainly would recommend including scalaVersion anyway. Note in particular that the effect of %% depends on what your scalaVersion is.

How to add native library dependencies to sbt project?

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.

Cross building in sbt with 2.10.0

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"