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
Related
I stumbled upon this Akka grpc tutorial which suggests that we can create a jar from a project that has .proto file under src/main/proto and add it as a dependency in client and server projects to build their respective stubs.
libraryDependencies += "com.example" %% "my-grpc-service" % "1.0.0" % "protobuf-src"
But this doesn't seem to work!! Are there any example projects that demonstrates how this would work in action? How can we externalize protobuf sources and use the same in a jvm based project?
I was able to figure out how to externalise protobuf files properly as per suggestion from akka-grpc docs.
The problem was that I was not adding sbt-akka-grpc plugin required by sbt to recognise .proto files and include them in the packaged jar. Without this plugin there won't be any .proto file made available in the packaged jar.
addSbtPlugin("com.lightbend.akka.grpc" % "sbt-akka-grpc" % "1.1.0")
Make sure to add organization settings in your build.sbt to prepare jar correctly.
organization := "com.iamsmkr"
Also, if you wish to cross-compile this jar to multiple versions add following entries in your build.sbt:
scalaVersion := "2.13.3"
crossScalaVersions := Seq(scalaVersion.value, "2.12.14")
and then to publish:
$ sbt +publishLocal
With appropriate jars published you can now add them as dependencies in your client and server projects like so:
libraryDependencies +=
"com.iamsmkr" %% "prime-protobuf" % protobufSourceVersion % "protobuf-src"
You can check out this project I am working on to see this in action.
Alternate Way
An alternate way I figured is that you can keep your .proto files in a root directory and then refer them in client and server build.sbt like so:
PB.protoSources.in(Compile) := Seq(sourceDirectory.value / ".." / ".." / "proto")
Checkout this project to see it in action.
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")
Say I want to include a dependency on the play-json library in my sbt file. How and where can I find that information?
I tried searching central repo, play git repository -- couldn't find anything.
First of all, when you want to include a dependency, you've somehow been told about it - about the required version and where to find it. Ask the person this question and you're done. The official source should always be the home page of a dependency.
I'd use http://search.maven.org/ or http://mvnrepository.com/ and pick whatever version is the most current. In your case, however, esp. after the comment where you pointed at Adding Play JSON Library to sbt the answer was right there - in the answers - see https://stackoverflow.com/a/20475410/1305344:
Play 2.2 is out and can be added separately from rest of Play
Framework. in build.sbt:
resolvers += "Typesafe Repo" at "http://repo.typesafe.com/typesafe/releases/"
libraryDependencies += "com.typesafe.play" %% "play-json" % "2.2.1"
The trick is to set up resolvers properly and using the above resolver gives http://repo.typesafe.com/typesafe/releases/com/typesafe/play/play-json_2.10.
When you've got resolvers and any version in your build configuration, you may want to use sbt-updates that's (quoting the plugin's headline) "SBT plugin that can check maven repositories for dependency updates". Quite handy to have it installed as a global plugin, i.e. .sbt/0.13/plugins/sbt-updates.sbt with the following:
resolvers += Classpaths.sbtPluginSnapshots
addSbtPlugin("com.timushev.sbt" % "sbt-updates" % "0.1.6-SNAPSHOT")
When you execute dependencyUpdates you're told what needs version update.
> dependencyUpdates
[info] Found 1 dependency update for superapp
[info] org.jacoco:org.jacoco.agent:jacoco : 0.6.4.201312101107 -> 0.6.5.201403032054 -> 0.7.0.201403182114
[success] Total time: 1 s, completed 2014-03-28 18:30:12
As you can see, I need to upgrade jacoco.
If the project you depend on releases to some known repositories, running sbt-updates regularly will ultimately tell you about the update. I'd strongly recommend reading RELEASE_NOTES for an update before upgrading since it may be introducing some breaking changes you'd rather know about before going to production.
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.
Now I somehow messed up my global sbt plugins (~/.sbt/plugins/build.sbt). They were always fine retrieved against Scala 2.9.1 which seems to be the version that sbt 0.11.3 wants, and all the plugins (sbt-gpg-plugin, sbt-idea-plugin) are published against 2.9.1.
Now whatever I do, it persistently tries to find them built against 2.9.2:
[warn] Note: Some unresolved dependencies have extra attributes. Check that these dependencies exist with the requested attributes.
[warn] com.github.mpeltonen:sbt-idea:1.0.0 (sbtVersion=0.11.3, scalaVersion=2.9.2)
[warn] com.jsuereth:xsbt-gpg-plugin:0.6 (sbtVersion=0.11.3, scalaVersion=2.9.2)
...
[error] {file:...}default-50be6e/*:update: sbt.ResolveException: unresolved dependency: com.github.mpeltonen#sbt-idea;1.0.0: not found
How can I fix this, so sbt retrieves the plugins for Scala 2.9.1 as before?
For the sake of completeness, this is how my files look after the suggestions:
// project-home/build.sbt
scalaVersion := "2.9.2"
...
// project-home/project/plugins.sbt
resolvers += "less is" at "http://repo.lessis.me"
addSbtPlugin( "me.lessis" % "ls-sbt" % "0.1.1" )
scalaVersion := "2.9.1" // "just in case it helps"
// ~/.sbt/plugins/build.sbt
scalaVersion := "2.9.1" // "just in case it helps"
resolvers += "sbt-idea-repo" at "http://mpeltonen.github.com/maven/"
resolvers += Resolver.url( "sbt-plugin-releases", url( "http://scalasbt.artifactoryonline.com/scalasbt/sbt-plugin-releases" ))( Resolver.ivyStylePatterns )
addSbtPlugin("com.github.mpeltonen" % "sbt-idea" % "1.0.0")
addSbtPlugin( "com.jsuereth" % "xsbt-gpg-plugin" % "0.6" )
What is even worse, the problem persists, even after I removed ~/.sbt/plugins/build.sbt. So there are no more references (at least visible to me) to either sbt-idea or xsbt-gpg-plugin. Still I cannot compile any project any more, because sbt still tries to find those two plugins. Epic fail.
You could provide the Scala version of plugin. I didn't use ~/.sbt/, but I think it will works too.
The following is my project configuration using Scala 2.9.2 as my project compiler, and using some pluign that are compiled from Scala 2.9.1. Since Scala 2.9.1 and Scala 2.9.2 is binary compatible, I don't encounter any problem yet.
// MyProject/build.sbt
name := "MyProject"
version := "0.1"
scalaVersion := "2.9.2"
The following is plugin configuration:
// File: MyProject/project/plugins.sbt
import sbt._
import Defaults._
resolvers += Resolver.url("sbt-plugin-releases",
new URL("http://scalasbt.artifactoryonline.com/scalasbt/sbt-plugin-releases/"))(
Resolver.ivyStylePatterns)
// Resolved to:
//
// http://..../com.untyped/sbt-less/scala_2.9.1/sbt_0.11.3/0.4/jars/sbt-less.jar
//
libraryDependencies += sbtPluginExtra(
m = "com.untyped" % "sbt-less" % "0.4", // Plugin module name and version
sbtV = "0.11.3", // SBT version
scalaV = "2.9.1" // Scala version compiled the plugin
)
Some references:
SBT plugins are versioned to the scala version they were built with.
You're not the only one... Again, no answers.
And another case study, this may have answers.
A possibly relevant quote? " Remember to also remove the project/plugins -directory, because if the directory exists, project/plugins.sbt is ignored."
You can also specify sbtVersion and scalaVersion. There is an overloaded addSbtPlugin -
addSbtPlugin(dependency : sbt.ModuleID, sbtVersion : scala.Predef.String, scalaVersion : scala.Predef.String)
Ok, I went back to all the events that could have led to this. And because I found that other projects were still building, I started to understand that the problem with this particular project B was that it appeared that the two plugins were regular dependencies of project A which it depended on.
When sbt refused to acknowledge the presence of the GPG plugin which I uncommented in ~/.sbt/plugins/build.sbt, I renamed that file to ~/.sbt/plugins.sbt, and back again. That intermediate position somehow meant that the plugins were not any more plugins (despite being added as addSbtPlugin), but regular dependencies for the project A when I publish that.
I tried to find that messed up A's ivy.xml across all known Ivy2 cache directories. It was not possible to find the one that sbt was obviously seeing.
Long story, short answer: I had to bump the version of A artificially to get rid of the wrong ivy.xml cached somewhere in a hidden place. That forced sbt to re-find A with the correct ivy.xml (not depending any more on the plugins).
Now I'm just worried what happens if I put my global plugin settings into place :-#
Future advise: Never ever ever put anything into ~/.sbt/plugins.sbt. If you need sbt to understand that you changed ~/.sbt/plugins/build.sbt: Reboot your computer. Don't touch any file.