Take the 2-minute tour ×

We want to use company internal ivy/maven repository (artifactory) to improve the speed of resolving, and downloading the jar files, and also we want to use it to exchange binary jar files between different teams in our organization.

I know we can force SBT to go through proxy by setting ~/.repositories with

  my-ivy-proxy-releases: http://repo.alpinenow.com/artifactory/repo/, [organization]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]
  my-maven-proxy-releases: http://repo.alpinenow.com/artifactory/repo/

and then launch SBT with -Dsbt.override.build.repos=true. This method works for me.

However, it's kind of cumbersome to ask all the developers to setup this way. We're wondering if we can override the default resolvers completely in Build.scala, and plugin.sbt without extra configuration.

So far, I've tried the following ways without success.

1) In both Build.scala and plugin.sbt, I added

resolvers := "Local Repo" at "http://repo.alpinenow.com/artifactory/repo/",

externalResolvers := Seq(Resolver.url("Local Repo", url("http://repo.alpinenow.com/artifactory/repo"))(Resolver.ivyStylePatterns)),

but it still downloads the jars from typesafe and maven1.

2) I then decided to put repositories file into project folder, and tried to add java option directly inside plugin.sbt, and Build.scala with

System.setProperty("-Dsbt.override.build.repos", "true"),

System.setProperty("-Dsbt.repository.config", "project/repositories"),

but it still doesn't work. I'm curious when the SBT gets the java options for resolvers since obviously, it's before plugin.sbt and Build.scala.

Any idea?


DB Tsai

share|improve this question
According to the offical documentation, shouldn't your repository config be in ~/.sbt/repositories, not ~/.repositories ? –  Luciano Mar 1 at 13:27

2 Answers 2

up vote 1 down vote accepted

If you depart from the sbt-extras shell script as a replacement for the default launcher script, I guess you could easily modify that with setting up ~/.repositories and adding -Dsbt.override.build.repos=true. Then all you need to do is ensure your developers use that script.

share|improve this answer
Yeah. If I can not find a way to do it just in Build.scala etc, I probably will replace the default launcher script. But it's the last way I will do. –  DB Tsai Oct 26 '13 at 21:57
In this end, we use this as our solution. Thanks. –  DB Tsai Oct 28 '13 at 21:36

I am always adding SBT build as part of my repo in SVN/GIT, close with code. Then I have no such problems.

It costs about 1MB space so is quite cheap and solves a lot of problems. All developers use identical build tool. Even if I try to create Continues Integration or more advanced Continues Delivery process all SBT configs will be already well configured in my SCM. I will get one source of true :)

share|improve this answer

Your Answer


