How to set up plugin downloads over SSL? - sbt

I have a SBT project that uses the sbt-start-script plugin. When I run SBT, the plugin jar is downloaded over unsecured HTTP instead of HTTPS:
downloading http://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/com.typesafe.sbt/sbt-start-script/scala_2.10/sbt_0.13/0.10.0/jars/sbt-start-script.jar ...
I want to use the https version of the repo instead (which I can browse to manually), but I can't figure out how get SBT to use it.
My project/plugins.sbt looks like this:
addSbtPlugin("com.typesafe.sbt" % "sbt-start-script" % "0.10.0")
I tried adding the https version to the SBT properties' [repositories] section and also tried adding it to the resolvers list, but SBT always uses the http version of the repo.
Does addSbtPlugin add the repo automatically?

tl;dr Create ~/.sbt/repositories with a https version or create a repositories file of different non-default name and run sbt with -Dsbt.override.build.repos=true and -Dsbt.repository.config=path-to-the-repositories-file.
Let's start with the default build definition - no additional setup but what comes with sbt itself.
show fullResolvers to know the external resolvers for automatically managed dependencies - there are three resolvers (formatting is mine to ease reading).
➜ https-repositories xsbt
...
> show fullResolvers
[info] ArrayBuffer(
Raw(ProjectResolver(inter-project, mapped: )),
FileRepository(local,FileConfiguration(true,None),Patterns(ivyPatterns=List(${ivy.home}/local/[organisation]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]), artifactPatterns=List(${ivy.home}/local/[organisation]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]), isMavenCompatible=false, descriptorOptional=false, skipConsistencyCheck=false)),
public: https://repo1.maven.org/maven2/)
Command Line Options says:
sbt.override.build.repos If true, repositories configured in a build definition are ignored and the repositories configured for the launcher are used instead. See sbt.repository.config and the sbt launcher documentation.
sbt.repository.config A file containing the repositories to use for the launcher. The format is the same as a [repositories] section for a sbt launcher configuration file. This setting is typically used in conjuction with setting sbt.override.build.repos to true (see previous row and the sbt launcher documentation).
That means that when sbt finds ~/.sbt/repositories with [repositories] inside they will become the resolvers for sbt.
Create ~/.sbt/repositories with the following content:
[repositories]
httpsInstead: https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/,[organization]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]
As you may have noticed, the file solely defines a https version of the repository in question.
reload the session (or start it over) and do show fullResolvers.
➜ https-repositories ls ~/.sbt/repositories
/Users/jacek/.sbt/repositories
➜ https-repositories xsbt
...
> show fullResolvers
[info] ArrayBuffer(
Raw(ProjectResolver(inter-project, mapped: )),
URLRepository(httpsInstead,Patterns(ivyPatterns=List(https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/[organization]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]), artifactPatterns=List(https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/[organization]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]), isMavenCompatible=false, descriptorOptional=false, skipConsistencyCheck=false)))
There are two resolvers now!
Let's use the sbt.* options - sbt.override.build.repos and sbt.repository.config.
➜ https-repositories ls ~/.sbt/my_repositories
/Users/jacek/.sbt/my_repositories
➜ https-repositories ls ~/.sbt/repositories*
zsh: no matches found: /Users/jacek/.sbt/repositories*
➜ https-repositories SBT_OPTS="-Dsbt.override.build.repos=false -Dsbt.repository.config=/Users/jacek/.sbt/my_repositories" xsbt
...
> show fullResolvers
[info] ArrayBuffer(
Raw(ProjectResolver(inter-project, mapped: )),
URLRepository(httpsInstead,Patterns(ivyPatterns=List(https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/[organization]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]), artifactPatterns=List(https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/[organization]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]), isMavenCompatible=false, descriptorOptional=false, skipConsistencyCheck=false)))
There are two resolvers again.
It appears that it doesn't change much with sbt.override.build.repos=true.
➜ https-repositories SBT_OPTS="-Dsbt.override.build.repos=true -Dsbt.repository.config=/Users/jacek/.sbt/my_repositories" xsbt
...
> show fullResolvers
[info] ArrayBuffer(
Raw(ProjectResolver(inter-project, mapped: )),
URLRepository(httpsInstead,Patterns(ivyPatterns=List(https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/[organization]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]), artifactPatterns=List(https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/[organization]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]), isMavenCompatible=false, descriptorOptional=false, skipConsistencyCheck=false)))
What's interesting is that with sbt.override.build.repos=true the resolvers change for sbt project builds.
This is a sample build.sbt with an imaginary repository:
resolvers += "build.sbt" at "http://my.repository.com"
The first session is with -Dsbt.override.build.repos=false:
➜ https-repositories SBT_OPTS="-Dsbt.override.build.repos=false -Dsbt.repository.config=/Users/jacek/.sbt/my_repositories" xsbt
...
> show fullResolvers
[info] ArrayBuffer(
Raw(ProjectResolver(inter-project, mapped: )),
URLRepository(httpsInstead,Patterns(ivyPatterns=List(https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/[organization]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]), artifactPatterns=List(https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/[organization]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]), isMavenCompatible=false, descriptorOptional=false, skipConsistencyCheck=false)),
build.sbt: http://my.repository.com)
Another session with -Dsbt.override.build.repos=true:
➜ https-repositories SBT_OPTS="-Dsbt.override.build.repos=true -Dsbt.repository.config=/Users/jacek/.sbt/my_repositories" xsbt
...
> show fullResolvers
[info] ArrayBuffer(
Raw(ProjectResolver(inter-project, mapped: )),
URLRepository(httpsInstead,Patterns(ivyPatterns=List(https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/[organization]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]), artifactPatterns=List(https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/[organization]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]), isMavenCompatible=false, descriptorOptional=false, skipConsistencyCheck=false)))

Related

Running sbt release task from cli for sub-project doesn't work

I have a multi-project sbt where I use sbt-release plugin. Everything works fine if I run release in a sub-project
> project reporter
[info] Set current project to reporter (in build file:/source/storage-integ/)
> release
[info] Starting release process off commit: c069698baf8bb6fca611ab4e7e086398aab473c5
[info] Checking remote [origin] ...
But this doesn't work when I run "sbt reporter/release" from cli. Where as "sbt reporter/compile" or "sbt reporter/assembly" do work.
$ sbt reporter/release
[warn] Executing in batch mode.
[warn] For better performance, hit [ENTER] to switch to interactive mode, or
[warn] consider launching sbt without any commands, or explicitly passing 'shell'
[info] Loading global plugins from /home/vagrant/.sbt/0.13/plugins
[info] Loading project definition from /source/storage-integ/project
[info] Set current project to root (in build file:/source/storage-integ/)
[error] Expected ':' (if selecting a configuration)
[error] Not a valid key: release (similar: releaseVcs, rpmRelease, rpm-release)
[error] reporter/release
This looks very similar to another SO post. I tried adding releaseSettings to build.sbt as suggested but it throws error
build.sbt:62: error: not found: value releaseSettings
I tried import sbtrelease.Release._ but that throws
error: object Release is not a member of package sbtrelease
At this point I feel the solution mentioned is no longer valid. Also, I don't see any reference to releaseSettings in sbt-release readme. Any idea how to get this working?
sbt.version = 0.13.15 && sbt-release: "1.0.6"
The release settings should be only in your root project. So, in order to have that:
First, your build.sbt could be something like this
lazy val root: Project = project.in(file("."))
.settings(Releases.settings: _*)
.aggregate(module1, module2)
Then, your project/Releases.scala like:
object Releases {
// You need to custom these to reflect your actual procedure
private val releaseProcess = Def.setting {
Seq[ReleaseStep](
checkSnapshotDependencies,
inquireVersions,
runClean,
runTest,
setReleaseVersion,
commitReleaseVersion,
tagRelease,
publishArtifacts,
setNextVersion,
commitNextVersion,
pushChanges
)
}
val settings = Seq(
releaseCommitMessage := s"Set version to ${(version in ThisBuild).value}",
releaseTagName := (version in ThisBuild).value,
releaseProcess := releaseProcess.value
)
}
By default you need a version.sbt with your current version. Lets say:
version in ThisBuild := "1.0.0-SNAPSHOT"
Then just:
sbt release

Why does "sbt stage" fail with Not a valid command?

I am getting errors when I try to stage my application using sbt clean compile stage:
[error] Not a valid command: stage
[error] Not a valid project ID: stage
[error] Expected ':' (if selecting a configuration)
[error] Not a valid key: stage
[error] stage
[error] ^
I have done this hundreds of times on other machines without a problem. I have SBT 0.13.5 -- has anyone seen this before? I have read this other post, but I'm not on Heroku. Thanks.
After the comments above I realized that you just wanted to have stage command without bringing the entire Play foo in.
The stage command is part of sbt-native-packager that:
The goal [of the plugin] is to be able to bundle up Scala software built with SBT for native packaging systems, like deb, rpm, homebrew, msi.
One of the features of the sbt-native-packager plugin is the stage command that
> help stage
Create a local directory with all the files laid out as they would be in the final distribution.
Just add the following to project/plugins.sbt to have the plugin available in the project (after the comment of Muki the example uses the latest version 1.0.0-M1 with the autoplugin feature):
addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "1.0.0-M1")
You will also have to add the following to build.sbt:
enablePlugins(JavaAppPackaging)
And that's it! You're all set now.
Execute stage.
> stage
[info] Packaging /Users/jacek/dev/sandbox/command-build-scala/target/scala-2.10/command-build-scala_2.10-0.1-SNAPSHOT-sources.jar ...
[info] Done packaging.
[info] Updating {file:/Users/jacek/dev/sandbox/command-build-scala/}command-build-scala...
[info] Wrote /Users/jacek/dev/sandbox/command-build-scala/target/scala-2.10/command-build-scala_2.10-0.1-SNAPSHOT.pom
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
[info] Packaging /Users/jacek/dev/sandbox/command-build-scala/target/scala-2.10/command-build-scala_2.10-0.1-SNAPSHOT-javadoc.jar ...
[info] Done packaging.
[info] Packaging /Users/jacek/dev/sandbox/command-build-scala/target/scala-2.10/command-build-scala_2.10-0.1-SNAPSHOT.jar ...
[info] Done packaging.
[success] Total time: 0 s, completed Nov 5, 2014 2:55:55 PM
After lots of digging, I found out 'stage' is implemented by a plugin from the Play framework, which I do use in my other projects and explains why sbt was accepting the stage command.

Why scalaInstance is different from scalaVersion in sbt?

build.sbt
val Backend = config("backend")
inConfig(Backend)(Defaults.configSettings)
scalaVersion in Backend := "2.11.2-SNAPSHOT"
sbt repl:
> show backend:scalaInstance
[info] Scala instance{version label 2.10.4, actual version 2.10.4, library jar: /home/masgui/.sbt/boot/scala-2.10.4/lib/scala-library.jar, compiler jar: /home/masgui/.sbt/boot/scala-2.10.4/lib/scala-compiler.jar}
> backend:scalaVersion
[info] 2.11.2-SNAPSHOT
current work arround:
lazy val v = Project(
id = "a",
base = file("woot"),
settings = Project.defaultSettings ++ Seq(
offline := true,
scalaVersion := "2.11.2-SNAPSHOT"
)
)
// ...
scalaInstance in (Backend, Revolver.reStart) := (scalaInstance in v).value
edit
When i add Classpaths.ivyBaseSettings to Backend it ignores ivyConfigurations += Backend
> show ivyConfigurations
[info] List(..., backend)
but
> backend:update
Cannot add dependency 'com.scalakata#backend_2.11;0.1-20140706T182100' to configuration 'backend' of module com.scalakata#plugin;0.1-20140709T150113 because this configuration doesn't exist!
edit
I solved this with one of your previous awnser: Copy a single dependency jar into a folder via build.sbt
TL;DR;
You have to also add Classpaths.ivyBaseSettings, Classpaths.jvmBaseSettings and Defaults.compileBase to your Backend configuration.
build.sbt
val Backend = config("backend")
inConfig(Backend)(Classpaths.ivyBaseSettings ++ Classpaths.jvmBaseSettings ++ Defaults.compileBase ++ Defaults.configSettings)
scalaVersion in Backend := "2.11.1"
Longer Version
The task scalaInstance is undefined in your Backend config, so sbt delegates to default scalaInstance.
[info] Delegates:
[info] backend:scalaInstance
[info] *:scalaInstance
[info] {.}/backend:scalaInstance
[info] {.}/*:scalaInstance
[info] */backend:scalaInstance
[info] */*:scalaInstance
If you check where it's defined, you can see it's in *:scalaInstance
> inspect definitions scalaInstance
[info]
[info] *:scalaInstance
If you want it to be defined you have to add Defaults.compileBase to your Backend configuration.
You can confirm it's not defined in the Backend scope.
> inspect definitions scalaInstance
[info]
[info] *:scalaInstance
[info] backend:scalaInstance
But that's not enough, if you check the output of the show backend:scalaInstance, you'll see that it's still 2.10.x.
> show backend:scalaInstance
[info] Scala instance{version label 2.11.1, actual version 2.10.4, library jar: /home/lpiepiora/.sbt/boot/scala-2.10.4/lib/scala-library.jar, compiler jar: /home/lpiepiora/.sbt/boot/scala-2.10.4/lib/scala-compiler.jar}
We need to configure the right classpath, by adding Classpaths.ivyBaseSettings ++ Classpaths.jvmBaseSettings.
The show backend:scalaInstance shows the right version.
> show backend:scalaInstance
[info] Scala instance{version label 2.11.1, actual version 2.11.1, library jar: /home/lpiepiora/.ivy2/cache/org.scala-lang/scala-library/jars/scala-library-2.11.1.jar, compiler jar: /home/lpiepiora/.ivy2/cache/org.scala-lang/scala-compiler/jars/scala-compiler-2.11.1.jar}
[success] Total time: 0 s, completed 08-Jul-2014 20:32:18

How to set up sbt-assembly to include jars with runtime scope?

How to set up sbt-assembly to include jars with runtime scope? What's the rationale for not doing it by default?
This is now being discussed under sbt/sbt-assembly#120.
sbt-assembly is intended to wire full classpath from Runtime configuration. And it's coded as follows:
fullClasspath in assembly <<= fullClasspath or (fullClasspath in Runtime),
For Spark, for whatever reason fullClasspath is wired, so that's likely interfering. The reason sbt-assembly included fullClasspath I think is now historical, so I might get rid of "fullClasspath or" part. As noted in the issue, the current workaround is likely:
fullClasspath in assembly := (fullClasspath in Runtime).value
FYI for those who learn sbt the above sbt-0.13+ format with := corresponds to the older pre-sbt-0.13 format with := as follows:
fullClasspath in assembly <<= (fullClasspath in Runtime)
My tests show that the plugin does include dependencies with runtime scope as evidenced with the following example.
project/plugins.sbt
addSbtPlugin("com.eed3si9n" % "sbt-assembly" % "0.11.2")
build.sbt
libraryDependencies += "ch.qos.logback" % "logback-classic" % "1.1.2" % "runtime"
assemblySettings
This is a sample session:
> about
[info] This is sbt 0.13.6-SNAPSHOT
[info] The current project is {file:/C:/dev/sandbox/runtime-assembly/}runtime-assembly 0.1-SNAPSHOT
[info] The current project is built against Scala 2.10.4
[info] Available Plugins: sbt.plugins.IvyPlugin, sbt.plugins.JvmPlugin, sbt.plugins.CorePlugin, sbt.plugins.JUnitXmlReportPlugin, org.sbtidea.SbtIdeaPlugin, de.johoop.jacoco4sbt.JacocoPlugin, com.timushev.sbt.updates.UpdatesPlugin, sbtassembly.Plugin
[info] sbt, sbt plugins, and build definitions are using Scala 2.10.4
> assembly
[info] Updating {file:/C:/dev/sandbox/runtime-assembly/}runtime-assembly...
[info] Resolving org.jacoco#org.jacoco.agent;0.6.4.201312101107 ...
[info] downloading http://repo1.maven.org/maven2/ch/qos/logback/logback-classic/1.1.2/logback-classic-1.1.2.jar ...
[info] [SUCCESSFUL ] ch.qos.logback#logback-classic;1.1.2!logback-classic.jar (1122ms)
[info] downloading http://repo1.maven.org/maven2/ch/qos/logback/logback-core/1.1.2/logback-core-1.1.2.jar ...
[info] [SUCCESSFUL ] ch.qos.logback#logback-core;1.1.2!logback-core.jar (1313ms)
[info] Done updating.
[info] Including: slf4j-api-1.7.6.jar
[info] Including: logback-classic-1.1.2.jar
[info] Including: logback-core-1.1.2.jar
[info] Including: scala-library.jar
[info] Checking every *.class/*.jar file's SHA-1.
[info] Merging files...
[warn] Merging 'META-INF\MANIFEST.MF' with strategy 'discard'
[warn] Strategy 'discard' was applied to a file
[info] SHA-1: 0f520cdfc30de8ced8408a3c25b326b3ff5afda8
[info] Packaging C:\dev\sandbox\runtime-assembly\target\scala-2.10\runtime-assembly-assembly-0.1-SNAPSHOT.jar ...
[info] Done packaging.
Jar verification:
/cygdrive/c/dev/sandbox/runtime-assembly
$ jar -tf target/scala-2.10/runtime-assembly-assembly-0.1-SNAPSHOT.jar | grep logback | wc -l
592

How to configure Typesafe Activator not to use user home?

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.

Resources