Why SBT 0.13.6 is downloading Scala 2.10.4 by default?
Even if in C:\Program Files (x86)\sbt\conf\sbtopts it is written Scala version (default: latest release) which seems to not be true.
C:\Users\Joan>sbt scala-version
Getting org.fusesource.jansi jansi 1.11 ...
:: retrieving :: org.scala-sbt#boot-jansi
confs: [default]
1 artifacts copied, 0 already retrieved (111kB/15ms)
Getting org.scala-sbt sbt 0.13.6 ...
:: retrieving :: org.scala-sbt#boot-app
confs: [default]
44 artifacts copied, 0 already retrieved (13750kB/563ms)
Getting Scala 2.10.4 (for sbt)...
:: retrieving :: org.scala-sbt#boot-scala
confs: [default]
5 artifacts copied, 0 already retrieved (24459kB/375ms)
[info] Set current project to joan (in build file:/C:/Users/Joan/)
[info] 2.10.4
Cheers
Because sbt is built on scala 2.10.4, as you can easily verify here.
In your own project, simply specify the scala version you indend to use in the same way sbt does, i.e. providing the scalaVersion build setting.
It's generally speaking a good idea not to depend on a default.
Related
I published some libraries using sbt publishLocal it worked and published to my ~/.ivy2/local dir.
I then have a project that depends on these libraries but sbt update can't find them.
specifically, my project has these dependencies:
lazy val myDependencies = commonDependencies ++ Seq(
"my.corp" %% "lib1" % "1.0.1-SNAPSHOT" withSources () withJavadoc (),
"my.corp" %% "lib2" % "2.0.2-SNAPSHOT" withSources () withJavadoc ()
)
sbt update has this error:
[error] (services / update) lmcoursier.internal.shaded.coursier.error.FetchError$DownloadingArtifacts: Error fetching artifacts:
[error] file:////home/myuser/.ivy2//local/my.corp/lib1_2.12/1.0.1-SNAPSHOT/jars/lib1.jar: not found: /home/myuser/.ivy2//local/my.corp/lib1_2.12/1.0.1-SNAPSHOT/jars/lib1.jar
[error] file://///home/myuser/.ivy2//local/my.corp/lib2_2.12/2.0.2-SNAPSHOT/jars/lib2.jar: not found: /home/myuser/.ivy2//local/my.corp/lib2_2.12/2.0.2-SNAPSHOT/jars/lib2.jar
when I look in the dir I can see the published jars but their name has the scala version appended, which is why the update resolving fails, I think :
$ ls /home/myuser/.ivy2/local/my.corp/lib1_2.12/1.0.1-SNAPSHOT/jars
lib1_2.12.jar lib1_2.12.jar.md5 lib1_2.12.jar.sha1
$ ls /home/myuser/.ivy2/local/my.corp/lib2_2.12/2.0.2-SNAPSHOT/jars
lib2_2.12.jar lib2_2.12.jar.md5 lib2_2.12.jar.sha1
If I publish to a repo for real I can resolve the libs.
Does anyone know the sbt incantation to fix this? ;-)
Cheers
Karl
Update:- I think coursier is the problem, not sure how to tell it to look for lib2_2_12.jar. Could it have a bad cached reference?
Caused by: lmcoursier.internal.shaded.coursier.cache.ArtifactError$NotFound: not found: /home/myuser/.ivy2/local/my.corp/lib2_2.12/2.0.2-SNAPSHOT/jars/lib2.jar
Update:-
disabling coursier worked
from the sbt REPL I can run
sbt:my-project> set ThisBuild / useCoursier := false
and then
sbt:my-project> update
and that worked, but setting it back to true update failed again, so this looks like a coursier issue.
Update:
coursier fetch from the command line worked!!
coursier fetch my.corp::lib1:1.0.1-SNAPSHOT --no-default -r central -r ivy2Local
downloaded the transitive dependencies and found my jar in my local ivy2 dir
so this is back to looking like an sbt - coursier interaction issue
I've just now run into this and after lots of diffs between an older working version and this non-working version I figured out that it is the withSources() that triggers the bug in sbt and/or coursier.
So, I have a SBT project, with two custom tasks jooq:codegen and flyway:migrate from [ https://github.com/sean8223/jooq-sbt-plugin, https://github.com/sean8223/flyway-sbt-plugin ]
Not that it is relevant here, but the flyway:migrate task creates the schema in the database, and jooq:codegen generates code from the schema. Hence, it is imperative that flyway:migrate runs before jooq:codegen. So, I added the following line in my build.sbt
(codegen in JOOQ) <<= (codegen in JOOQ) dependsOn (migrate in Flyway)
Also, compile needs the generated code from jooq:codegen, but the plugin takes care of it by default.
Here is the weird part. When I run sbt compile, I get:
~/N/p/d/davion git:data-access ❯❯❯ sbt compile
[info] Loading project definition from /Users/rohan/Nomadly/projects/davion-projects/davion/project
[info] Set current project to davion (in build file:/Users/rohan/Nomadly/projects/davion-projects/davion/)
[info] Done updating.
[info] Initialising properties : /jooq-config4460313300896426081.xml
... OUTPUT TRUNCATED ...
[info] Table records generated : Total: 669.172ms, +44.536ms
[info] Routines fetched : 0 (0 included, 0 excluded)
[info] Packages fetched : 0 (0 included, 0 excluded)
[info] GENERATION FINISHED! : Total: 688.254ms, +19.082ms
[info] Compiling 7 Scala sources and 17 Java sources to /Users/rohan/Nomadly/projects/davion-projects/davion/target/classes...
[success] Total time: 24 s, completed 14 May, 2015 12:13:35 PM
So, the flyway:migrate task doesn't run. But when I run sbt jooq:codegen, this happens:
~/N/p/d/davion git:data-access ❯❯❯ sbt jooq:codegen
[info] Loading project definition from /Users/rohan/Nomadly/projects/davion-projects/davion/project
[info] Set current project to davion (in build file:/Users/rohan/Nomadly/projects/davion-projects/davion/)
[info] Flyway (Command-line Tool) v.2.0.3
[info]
[info] Current schema version: 6
[info] Schema is up to date. No migration necessary.
[info] Initialising properties : /jooq-config6431105742854017589.xml
[info] License parameters
... OUTPUT TRUNCATED ...
I have no idea why this is happening. If a task chain is setup where 'A' depends on 'B' which depends on 'C', then shouldn't running 'A' execute both 'C' and 'B' (and in that order)? Why does 'C' not run as a transitive dependency and how can I remedy this?
When starting Typesafe Activator using activator ui, there are messages starting with Getting. What do sbt-rc-probe-0-13 and sbt-rc-ui-interface-0-13 do for activator?
➜ no-trace-deps activator ui
Checking for a newer version of Activator (current version 1.2.10)...
... our current version 1.2.10 looks like the latest.
Found previous process id: 36033
FOUND REPO = activator-local # file:/usr/local/Cellar/typesafe-activator/1.2.10/libexec/repository
Play server process ID is 39625
[info] play - Application started (Prod)
[info] play - Listening for HTTP on /127.0.0.1:8888
[info] a.e.s.Slf4jLogger - Slf4jLogger started
Getting com.typesafe.sbtrc sbt-rc-probe-0-13 1.0-c50ddab5e1332398049a2a649261e1ca24577479 ...
downloading file:/usr/local/Cellar/typesafe-activator/1.2.10/libexec/repository/com.typesafe.sbtrc/sbt-rc-probe-0-13/1.0-c50ddab5e1332398049a2a649261e1ca24577479/jars/sbt-rc-probe-0-13.jar ...
[SUCCESSFUL ] com.typesafe.sbtrc#sbt-rc-probe-0-13;1.0-c50ddab5e1332398049a2a649261e1ca24577479!sbt-rc-probe-0-13.jar (12ms)
:: retrieving :: org.scala-sbt#boot-app
confs: [default]
2 artifacts copied, 0 already retrieved (414kB/8ms)
Getting com.typesafe.sbtrc sbt-rc-ui-interface-0-13 1.0-c50ddab5e1332398049a2a649261e1ca24577479 ...
downloading file:/usr/local/Cellar/typesafe-activator/1.2.10/libexec/repository/com.typesafe.sbtrc/sbt-rc-ui-interface-0-13/1.0-c50ddab5e1332398049a2a649261e1ca24577479/jars/sbt-rc-ui-interface-0-13.jar ...
[SUCCESSFUL ] com.typesafe.sbtrc#sbt-rc-ui-interface-0-13;1.0-c50ddab5e1332398049a2a649261e1ca24577479!sbt-rc-ui-interface-0-13.jar (4ms)
:: retrieving :: org.scala-sbt#boot-app
confs: [default]
1 artifacts copied, 0 already retrieved (32kB/4ms)
[info] application - error getting name from sbt: sbt process never got in touch, so unable to handle request NameRequest(true)
[info] application - using file basename as app name: no-trace-deps
[INFO] [09/26/2014 19:41:14.587] [default-akka.actor.default-dispatcher-3] [akka://default/user/app-no-trace-deps-1/socket] Firing up web socket
These were part of the old sbt-remote-control API (the prototype for sbt server).
The "probe" is what sits inside sbt and communicates task results/commands to/from the activator process and the sbt server.
The 'ui-interface' is an API where plugins can directly send messages to activator from within sbt.
These will make a bit more sense with the new sbt-server pre-release where "ui-interface" is renamed "server-interface" (I think) and the Play plugin can directly communicate to clients (like IDEs/Activator).
I'd like to configure Typesafe Activator and it's bundled tooling not to use my user home directory - I mean ~/.activator (configuration?), ~/.sbt (sbt configuration?) and especially ~/.ivy2, which I'd like to share between my two OSes.
Typesafe "documentation" is of little help.
Need help for both Windows and Linux, please.
From Command Line Options in the official documentation of sbt:
sbt.global.base - The directory containing global settings and plugins (default: ~/.sbt/0.13)
sbt.ivy.home - The directory containing the local Ivy repository and artifact cache (default: ~/.ivy2)
It appears that ~/.activator is set and used in the startup scripts and that's where I'd change the value.
It also appears (in sbt/sbt.boot.properties in activator-launch-1.2.1.jar) that the value of ivy-home is ${user.home}/.ivy2:
[ivy]
ivy-home: ${user.home}/.ivy2
checksums: ${sbt.checksums-sha1,md5}
override-build-repos: ${sbt.override.build.repos-false}
repository-config: ${sbt.repository.config-${sbt.global.base-${user.home}/.sbt}/repositories}
It means that without some development it's only possible to change sbt.global.base.
➜ minimal-scala activator -Dsbt.global.base=./sbt -Dsbt.ivy.home=./ivy2 about
[info] Loading project definition from /Users/jacek/sandbox/sbt-launcher/minimal-scala/project
[info] Set current project to minimal-scala (in build file:/Users/jacek/sandbox/sbt-launcher/minimal-scala/)
[info] This is sbt 0.13.5
[info] The current project is {file:/Users/jacek/sandbox/sbt-launcher/minimal-scala/}minimal-scala 1.0
[info] The current project is built against Scala 2.11.1
[info] Available Plugins: sbt.plugins.IvyPlugin, sbt.plugins.JvmPlugin, sbt.plugins.CorePlugin, sbt.plugins.JUnitXmlReportPlugin
[info] sbt, sbt plugins, and build definitions are using Scala 2.10.4
If you want to see under the hood, you could query for the current values of the home directories for sbt and Ivy with consoleProject command (it assumes you started activator with activator -Dsbt.global.base=./sbt -Dsbt.ivy.home=./ivy2):
> consoleProject
[info] Starting scala interpreter...
[info]
import sbt._
import Keys._
import _root_.sbt.plugins.IvyPlugin
import _root_.sbt.plugins.JvmPlugin
import _root_.sbt.plugins.CorePlugin
import _root_.sbt.plugins.JUnitXmlReportPlugin
import currentState._
import extracted._
import cpHelpers._
Welcome to Scala version 2.10.4 (Java HotSpot(TM) 64-Bit Server VM, Java 1.7.0_60).
Type in expressions to have them evaluated.
Type :help for more information.
scala> appConfiguration.eval.provider.scalaProvider.launcher.bootDirectory
res0: java.io.File = /Users/jacek/sandbox/sbt-launcher/minimal-scala/sbt/boot
scala> appConfiguration.eval.provider.scalaProvider.launcher.ivyHome
res1: java.io.File = /Users/jacek/.ivy2
Iff you're really into convincing Activator to use sbt.ivy.home, you have to change sbt/sbt.boot.properties in activator-launch-1.2.2.jar. Just follow the steps:
Unpack sbt/sbt.boot.properties out of activator-launch-1.2.2.jar.
jar -xvf activator-launch-1.2.2.jar sbt/sbt.boot.properties
Edit sbt/sbt.boot.properties and replace ivy-home under [ivy].
ivy-home: ${sbt.ivy.home-${user.home}/.ivy2}
Add the changed sbt/sbt.boot.properties to activator-launch-1.2.2.jar.
jar -uvf activator-launch-1.2.2.jar sbt/sbt.boot.properties
With the change, -Dsbt.ivy.home=./ivy2 works fine.
scala> appConfiguration.eval.provider.scalaProvider.launcher.bootDirectory
res0: java.io.File = /Users/jacek/sandbox/sbt-launcher/minimal-scala/sbt/boot
scala> appConfiguration.eval.provider.scalaProvider.launcher.ivyHome
res1: java.io.File = /Users/jacek/sandbox/sbt-launcher/minimal-scala/ivy2
I was experimenting with this today. After a while, it seems to me like this could be the best thing to do:
Windows:
setx _JAVA_OPTIONS "-Duser.home=C:/my/preferred/home/"
Linux:
export _JAVA_OPTIONS='-Duser.home=/local/home/me'
Then you should be good to go for any Java Program that wants to store data in your home directory.
As an addition to Jacek's answer, another way that worked for me to set the .ivy2 directory was to use the sbt ivyConfiguration task. It returns configuration settings related to ivy, including the path to the ivy home (the one which defaults to ~/.ivy2).
Simply add these few lines to the build.sbt file in your project :
ivyConfiguration ~= { originalIvyConfiguration =>
val config = originalIvyConfiguration.asInstanceOf[InlineIvyConfiguration]
val ivyHome = file("./.ivy2")
val ivyPaths = new IvyPaths(config.paths.baseDirectory, Some(ivyHome))
new InlineIvyConfiguration(ivyPaths, config.resolvers, config.otherResolvers,
config.moduleConfigurations, config.localOnly, config.lock,
config.checksums, config.resolutionCacheDir, config.log)
}
It returns a new ivy configuration identical to the original one, but with the right path to the ivy home directory (here ./.ivy2, so it'll be located just next to the build.sbt file). This way, when sbt uses the ivyConfiguration task to get the ivy configuration, the path to the .ivy2 directory will be the one set above.
It worked for me using sbt 0.13.5 and 0.13.8.
Note: for sbt versions 0.13.6 and above, the construction of the InlineIvyConfiguration needs an additional parameter to avoid being flagged as deprecated, so you might want to change the last line into :
new InlineIvyConfiguration(ivyPaths, config.resolvers, config.otherResolvers,
config.moduleConfigurations, config.localOnly, config.lock,
config.checksums, config.resolutionCacheDir, config.updateOptions, config.log)
(note the additional config.updateOptions)
I had that same problem on Mac. I erased the directory in user home directory named .activator and all related folder. After that run activator run command on terminal. Activator download all of the folder which I deleted. Than problem solved.
I am getting deprecation and feature warnings when compiling my SBT project definition (i.e. the files inside the project directory). SBT version is 0.13.0.
I do not get more info on these by setting scalacOptions := Seq("-feature", "-deprecation"), this only seems to work for project source files and not project definition files.
Anyone know how I can set deprecation and warning for the compiler when it compiles the project definition?
[info] Loading project definition from /home/xxx/website/project
[warn] there were 2 deprecation warning(s); re-run with -deprecation for details
[warn] there were 4 feature warning(s); re-run with -feature for details
[warn] two warnings found
Create project/build.sbt project definition file with the following content:
scalacOptions := Seq("-feature", "-deprecation")
Since any *.sbt file under project belongs to the meta (build) project, it sets up the Scala compiler for the build configuration not the environment for the project under build.
It was tested with a sample sbt multi-project:
[info] Compiling 1 Scala source to /Users/jacek/sandbox/so/multi-0.13.1/project/target/scala-2.10/sbt-0.13/classes...
[warn] /Users/jacek/sandbox/so/multi-0.13.1/project/Build.scala:4: method error in object Predef is deprecated: Use `sys.error(message)` instead
[warn] lazy val e = error("Launcher did not provide the Ivy home directory.")
[warn] ^
[warn] one warning found
...when it compiled the following project/Build.scala:
import sbt._
object Build extends Build {
lazy val e = error("Launcher did not provide the Ivy home directory.")
}