When I build an artefact with
sbt universal:packageZipTarball
the scala-compiler.jar is included as a lib in my artefact.
Why is the scala-compiler needed at runtime? In my understanding it shouldn't be needed.
How can I exclude this jar?
It is probably pulled in as a transitive dependency by one of your libraryDependencies. You can use this sbt plugin to find out which one:
https://github.com/sbt/sbt-dependency-graph
Once you found out, you can block it by appending exclude("org.scala-lang", "scala-compiler") to the relevant dependency.
For instance, older versions of the pureconfig library used to erroneously pull this dependency in. It can be fixed like so:
libraryDependencies +=
"com.github.pureconfig" %% "pureconfig" % "0.10.0" exclude("org.scala-lang", "scala-compiler")
Related
I have this line of code in my build.sbt file:
libraryDependencies ++= Seq("com.foo" %% "lib" % "1.2.3")
Imagine that this library depends on "com.bar.lib" lib. Now in my code I can import com.bar.lib._ and it'll work. But I don't want this to compile, so maybe there is SBT plugin out there just for this purpose?
One of libraries I'm using depends on old cats version. I spent really long time to understand why mapN method not works... I just never imported a newer version of cats in the subproject.
SBT offers the intransitive and exclude features to deal with issues like this, as #earldouglas points out. See: https://www.scala-sbt.org/1.x/docs/Library-Management.html
You replied:
I tried to do so, but intransitive() don't import transitive dependencies (so I need to import all of them by hand to make it compile).
Yes, that is what it is for
What I want is something that will warn me about using libraries not directly imported in SBT file.
So you want transitive dependencies on your classpath, but you want the compiler to reject uses of transitive classes in your project code while allowing them in library code?
That is not a sensible approach: at runtime, these transitive dependencies will be on the classpath. The JVM classpath does not distinguish between different kinds of dependencies; such distinction only exists in SBT at build time.
You would be much better served by either
including a newer version of the cats library, overriding the transitive dep or
excluding the transitively included cats library, if it is broken.
However, I think you probably could achieve what you want by setting different dependencies at different build stages:
at Compile stage, include the dependency with intransitive. Your code should compile against your direct dependencies, but fail if you referenced any transitive dependencies
at Runtime stage, include the dependency with its transitive deps
the SBT code might look like this (untested):
(libraryDependencies in Compile) ++= Seq("com.foo" %% "lib" % "1.2.3" intransitive())
(libraryDependencies in Runtime) ++= Seq("com.foo" %% "lib" % "1.2.3")
In my project I want to use the sbinary library to (de)serialize some case classes to a binary form. I also want to use the latest Scala in the project. Typesafe offers a version of sbinary in their repositories, and they seem to be the only one who are doing so.
So I add the repository and dependency to my build.sbt like so:
scalaVersion := "2.11.2"
resolvers += "Typesafe Repository" at "http://repo.typesafe.com/typesafe/releases/"
libraryDependencies += "org.scala-tools.sbinary" %% "sbinary" % "0.4.2"
Surprisingly, this fails. With a dependency defined like this, SBT tries to find the dependency at the url http://repo.typesafe.com/typesafe/releases/org/scala-tools/sbinary/sbinary_2.11.0 whereas it is really located at http://repo.typesafe.com/typesafe/releases/org.scala-tools.sbinary/sbinary_2.11.0. Because SBT replaces the dots in the dependency group id with slashes, it is not able to find the dependency in the place it's in.
I've tried some tricks for building the string in other ways, but they are all useless since SBT replaces the .s by /s in the string after it is evaluated. How can I get SBT to find the dependency at this URL?
Please note that I'm aware that I could simply make this an offline dependency, but I'd prefer to have this build script work out of the box on any computer with SBT installed.
http://repo.typesafe.com/typesafe/releases/org.scala-tools.sbinary/sbinary_2.11.0 is in ivy style. The default style of sbt is maven2 so your resolver doesn't work.
try
resolvers += Resolver.url("Typesafe Repository (ivy)", url("http://repo.typesafe.com/typesafe/releases/"))(Resolver.ivyStylePatterns)
Source: https://groups.google.com/forum/#!topic/simple-build-tool/TY1AoYYvB4k
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've written an sbt plugin called sbt-jumi which implements sbt integration for Jumi. Right now the sbt-jumi plugin depends on the current Jumi release.
Here is the relevant line from the plugin's build.sbt:
libraryDependencies += "fi.jumi" % "jumi-launcher" % "0.5.376"
And a user of the plugin would add this to his project/plugins.sbt file:
addSbtPlugin("fi.jumi.sbt" % "sbt-jumi" % "0.1.0")
Now let's say that Jumi 0.6.400 is released and it's backward compatible. How can a user of the sbt-jumi plugin configure it to use Jumi 0.6.400, without me having to release a new version of the plugin?
Here is how to do it in Maven. But how to do it in sbt?
Overriding the dependencies of plugins happens the same way as overriding normal dependencies, except that the configuration must be entered into project/plugins.sbt. Overriding dependencies is explained in Library Management. Here is a summary:
If the version you wish to use is greater than the dependency that you would get transitively, sbt will use the larger version by default. You may change the conflict manager to change the default behavior - for example this will create an error on conflict:
conflictManager := ConflictManager.strict
In other words, this in project/plugins.sbt would work:
libraryDependencies += "fi.jumi" % "jumi-launcher" % "0.6.400"
You may check your plugin dependencies using reload plugins and then show update. It should now show the older version as "(EVICTED)".
If the version you wish to use is lower than the default dependency, then you will need to override differently. One way is to force the dependency:
libraryDependencies += "fi.jumi" % "jumi-launcher" % "0.4.350" force()
Another way is to use the dependencyOverrides setting:
dependencyOverrides += "fi.jumi" % "jumi-launcher" % "0.4.350"
The difference between the two methods is that overriding doesn't introduce a direct dependency. I don't think the difference matters for plugins, but for published artifacts it has some differences.
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"