I'm trying to build the lunatech-securesocial-poc project with scala 2.11.2 and I've updated the scalaVersion in projects/Build.scala. This project depends on securesocial, which I've built locally with 2.11.2 and named its artifact version master-SNAPSHOT. I've updated the dependency in lunatech-securesocial-poc's project to use this version of securesocial. However, SBT (activator) fails to compile because it is looking for ws.securesocial#securesocial_2.10;master-SNAPSHOT. How can I find out what is causing the scala version to be overridden to 2.10. I want 2.11.2. Obviously some dependency is forcing it, but I want to find out what that dependency is, and fix it.
I've tried adding:
dependencyOverrides += "org.scala-lang" % "scala-library" % scalaVersion.value
evictionWarningOptions := EvictionWarningOptions.default.withWarnTransitiveEvictions(true).withWarnDirectEvictions(true).withWarnScalaVersionEviction(true)
ivyScala := ivyScala.value map { _.copy(overrideScalaVersion = true) }
to my Build.scala and I'm using SBT version 0.13.7. I don't see why it is so hard for SBT to just abort and tell me that XXX dependency is preventing it from using 2.11.2 and requiring 2.10.
Anyone?
You can use sbt-dependency-graph plugin to find this out.
The issue turned out to be in my Build.scala. While I defined scalaVersion and used it in setting up dependencies, I didn't pass a setting to the Project that overrode the default scalaVersion, which evidently is the one used to build activator (2.10.4). So despite thinking I had set scalaVersion, I hadn't really.
Related
I'm trying to create jar file from scala file - which will be used for Scalatron bot (http://scalatron.github.io/)
The problem is that if I create jar file using new scala versions 2.10 - 2.13 (these are the only one's that InteliJJ allows me to use) scalatron bot doesn't work.
However I found out that downgrading to scala 2.9.2 fixes the problem (Getting Scalatron to Work (trouble with opcode)).
How to downgrade to 2.9.2 on Intellij?
SBT is fully integrated with IntelliJ Idea, so you can create a SBT project in IntlliJ and make up the build.sbt file by yourself and put in it the scala version you want, compile, package and execute with SBT
name := "scalatron"
version := "0.1"
scalaVersion := "2.9.2"
libraryDependencies += "org.scalatest" %% "scalatest" % "3.2.0-SNAP3" % Test
I have a CLI app which compile only to 2.11 (because of some internal dependency).
I want to package this app as a sbt plugin. This sbt plugin run the app by forking the JVM, running separately with its own classpath to avoid Scala library conflict.
Obviously I need to download the scala 2.11 app with all its dependencies and I am using a custom Configuration for it. My issue is that when I try to list the dependencies it comes with the scala library configured by the project.
Specific code is here : https://github.com/thibaultdelor/CliAppSbtPlugin/blob/master/plugin/src/main/scala/com/thibaultdelor/MyWrapperPlugin.scala#L33
autoScalaLibrary in CliConfig := false,
libraryDependencies ++= Seq(
"org.scala-lang" % "scala-library" % "2.11.12" % CliConfig,
"com.thibaultdelor" % "mycli_2.11" % "0.0.1" % CliConfig
)
val dependencies = (update in CliConfig).value.select(configurationFilter(CliConfig.name))
Here, if the project has the scala version 2.12, dependencies will contains scala-library 2.12 instead of what 2.11 as I would like.
Any help welcome, I am stuck. The sample project is on github and has a failing test case for it.
When upgrading our build from 12.4 to 13.1 I observed that although the build specified scalaVersion := "2.10.2", the resulting archive (created via the sbt-pack plugin) contained scala-library-2.10.3.jar. A quick check confirmed that the 12.4 build was including scala-library-2.10.2.jar.
It appears that sbt 0.13 included a change to treat the scala libraries as normal dependencies, with the consequence that if a project dependency was built with a later 2.10.x version of scala then that transitive dependency will "win" the ivy dependency resolution conflict resolution, and the compile, test and run classpaths will contain the later version of scala libraries.
Is this the desired behavior, or a bug in sbt 0.13?
If the desired behavior, then does that mean I have to use the mechanisms to "force/override" the conflict resolution to use my desired version of the scala libraries? (If so, the scalaVersion configuration setting seems a bit pointless....)
Here is an extremely minimal test case to illustrate the behavior:
test-proj/
build.sbt
project/
build.properties
build.sbt:
scalaVersion := "2.10.2"
//scalaVersion := "2.10.3"
libraryDependencies += "com.typesafe.akka" %% "akka-actor" % "2.3.0"
//libraryDependencies += "com.typesafe.akka" %% "akka-actor" % "2.2.4"
build.properties:
sbt.version=0.13.1
Akka 2.2.4 was built against scala 2.10.2, so firing up sbt and running "update", "show update", "show compile:dependencyClasspath", "show test:dependencyClasspath" and "show runtime:dependencyClasspath" all show scala-library 2.10.2 on the classpath.
Switching to Akka 2.3.0, which was built against scala 2.10.3, results in scala-library 2.10.3 appearing on all the classpaths, and "show update" clearly shows 2.10.2 being evicted by Ivy's conflict resolution.
Interestingly (and inconsistently), entering the REPL in both cases (via the sbt console command) results in scala 2.10.2 being utilized.
According to the docs, in sbt 0.13
The scalaVersion configures the version of Scala used for compilation. By default, sbt also adds a dependency on the Scala library with this version.
Based on that, I would expect the compilation classpath above to include 2.10.2 in both circumstances.
However, the release notes for 0.13 say
Scala dependencies (like scala-library and scala-compiler) are now resolved via the normal update task
which does at least explain the observed behavior.
sbt 0.13.0 Changes
You wrote:
It appears that sbt 0.13 included a change to treat the scala libraries as normal dependencies, with the consequence that if a project dependency was built with a later 2.10.x version of scala then that transitive dependency will "win" the ivy dependency resolution conflict resolution, and the compile, test and run classpaths will contain the later version of scala libraries.
sbt 0.13.0 Changes has somewhat conflicting note on this issue. Features, fixes, changes with compatibility implications section says:
sbt no longer overrides the Scala version in dependencies. This allows independent configurations to depend on different Scala versions and treats Scala dependencies other than scala-library as normal dependencies. However, it can result in resolved versions other than scalaVersion for those other Scala libraries.
Resolving Scala dependencies section says:
Scala dependencies (like scala-library and scala-compiler) are now resolved via the normal update task.
(Emphasis added by Eugene) So the quick answer to your "Is this the desired behavior, or a bug in sbt 0.13?" as you've already answered yourself is: In sbt 0.13.x, this behavior seems to be intended. Akka 2.3.0 depends on scala-library 2.10.3, and Ivy has evicted scala-library 2.10.2 in favor of 2.10.3.
dependencyOverrides
To workaround this, you can use dependencyOverrides setting as follows:
dependencyOverrides += "org.scala-lang" % "scala-library" % scalaVersion.value
Before:
sbt-so-22551430> show fullClasspath
[info] List(... Attributed(/Users/xxx/.sbt/0.13/boot/scala-2.10.3/lib/scala-library.jar) ...)
After:
sbt-so-22551430> show fullClasspath
[info] List(... Attributed(/Users/xxx/.ivy2/cache/org.scala-lang/scala-library/jars/scala-library-2.10.2.jar) ...)
Is this behavior desirable?
Your question was not whether if this is by design, but if this is desirable. I think the current behavior is quite surprising, and sbt should at least improve on notifying the build users of this behavior. And perhaps change its default Ivy conflict management policy to force() the version specified in scalaVersion. Here are two GitHub issues I created:
shell should display all evicted libraries on start up #1200
provide some means of forcing scala-library version to scalaVersion #1201
I am trying a very simple sbt example; when I compile it with sbt, and always get the following error:
org.scala-sbt#sbt_2.9.1;0.12.3: not found
I found a build.properties file under project folder, where I could change the 0.12.3 part; for example, after I changed it to 0.11.3, it will succeed until another inompatible issue; However, I want to know how to change sbt_2.9.1 to, say, sbt_2.9.2; I don't find a configuration file, and even I update the sbt to the latest version 0.12.3, still no luck.
my build.sbt file:
organization := "com.typesafe.slick"
name := "slick-examples"
version := "1.0.1-RC1"
scalaVersion := "2.10.1"
scalacOptions += "-deprecation"
anyone please help me.
The Scala version sbt is using internally and the one used for your project are totally independent. Which sbt launcher are you using? Make sure you are using an sbt.version property that works for your sbt launcher.
Again, no need to configure the Scala version for your project at that level. Write a build.sbt file and set scalaVersion to, e.g. 2.10.1 (assuming you use sbt 0.12.x): scalaVersion := 2.10.1
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.