My question is: Why can't I publish from SBT to my server via SSH?
Context:
I am developing a scala library and I want to publish it to a remote repository with SBT v0.12.3 over SSH (using an SFTP resolver). The relevant portion of my project/Build.scala SBT settings file is configured as prescribed by https://github.com/harrah/xsbt/wiki/Resolvers:
publishTo <<= version { v =>
Some(Resolver.sftp(
"My Repository",
"example.com",
"/var/www/public_html/repositories/" + (
if (v.trim.endsWith("SNAPSHOT")) { "snapshots" } else { "releases" }
)
))
},
resolvers ++= Seq(
{
import java.io.File
val privateKeyFile: File = new File(sys.env("HOME") + "/.ssh/id_rsa")
Resolver.ssh("scala-sh", "example.com") as("my-username", privateKeyFile) withPermissions("0644")
},
...
),
When I run sbt publish, things go fine until the authorization, where it still attempts to prompt me for login/password. When I run it locally, it brings up the username/password prompt, and when I try to publish remotely while SSH'd in to a machine it fails with a java.awt.HeadlessException. The result appears to be that the desired private-key type of authentication is not being attempted.
Here is a log of the remote session publish attempt:
> sbt-version
[info] 0.12.3
> publish
[info] Packaging /home/me/my-lib/target/scala-2.10.1/my-lib_2.10.1-SNAPSHOT-sources.jar ...
[info] Done packaging.
[info] Wrote /home/me/my-lib/target/scala-2.10.1/my-lib_2.10.1-SNAPSHOT.pom
[info] :: delivering :: org.example#my-lib_2.10.1;SNAPSHOT :: SNAPSHOT :: release :: Sun Apr 21 12:48:59 PDT 2013
[info] delivering ivy file to /home/me/my-lib/target/scala-2.10.1/ivy-SNAPSHOT.xml
[info] Generating API documentation for main sources...
model contains 75 documentable templates
[info] API documentation generation successful.
[info] Packaging /home/me/my-lib/target/scala-2.10.1/my-lib_2.10.1-SNAPSHOT-javadoc.jar ...
[info] Done packaging.
[info] Packaging my-lib-SNAPSHOT.jar ...
[info] Done packaging.
[trace] Stack trace suppressed: run last *:publish for the full output.
[error] (*:publish) java.awt.HeadlessException:
[error] No X11 DISPLAY variable was set, but this program performed an operation which requires it.
[error] Total time: 35 s, completed Apr 21, 2013 12:49:33 PM
It fails because there is no X11 display. This is unexpected behavior because the SBT project configuration is set to use private key authentication (see resolvers above).
So far I can think of 2 possible causes for the problem, detailed below.
Possible cause #1: Misconfiguration of SBT
Is there a problem in my configuration above?
Possible cause #2: Hitting an Ivy bug from an old version
At time of writing, I am using the latest SBT, 0.12.3. Maybe the version of Ivy being used by SBT is old. The more I think about it, the less likely this seems, but I haven't been able to rule it out yet.
How can I find out what version of Ivy SBT is using?
and then..
IF it is old, is there a way to get SBT to use a newer version of ivy?
There is another relevant question, see ivy ssh publisher, which references[0] an Old Ivy bug which caused java.awt.HeadlessExceptions.
[0] ivy ssh publisher
"Which version of Ivy are you using? There is a Jira Bug for Version 2.0 : issues.apache.org/jira/browse/IVY-783 which should be fixed now."
"Seems like if I upgrade to ivy 2.3 rc-2. SSH publish works."
It may after all be an Ivy version related bug. I am using SBT 0.12.2, which AFAIK is using Ivy 2.0. I am looking at the Ivy cache, located in ~/.ivy2/cache/, where Ivy creates a bunch of XML log files for the dependencies it has resolved, and I can see Ivy module version 2.0 in every XML file generated.
I don't know of a way to update the Ivy version used by SBT, but judging by the default SBT documentation, a possible solution is to manually upgrade Ivy and make sure the default machine wide path points to the right Ivy version.
Then run sbt clean or sbt update to re-fetch dependencies and allow Ivy to regenerate XML config files, etc. for the new Ivy version. More on SBT dependency management HERE:
Ivy Home Directory
By default, sbt uses the standard Ivy home directory location
${user.home}/.ivy2/. This can be configured machine-wide, for use by
both the sbt launcher and by projects, by setting the system property
sbt.ivy.home in the sbt startup script (described in Setup).
For example:
java -Dsbt.ivy.home=/tmp/.ivy2/ ...
Update
By checking the SBT Scala source code for the latest version, the version issue is confirmed again. Even SBT 0.13 appears to be using Ivy version 2.0.0, not 2.3. Have a look at the SBT source code, specifically the last few lines of THIS file.
Related
When I run SBT in my Scala project that contains a build.sbt file, SBT seems to ignore it and loads the project definition from a different folder and set the current project to that different directory hsperfdata which is weird because this is used as part of Java's performance counter which has nothing to do with what I'm trying to do.
Also SBT was installed via SDKMAN and when I try to specify a lower SDK version 1.2.8 instead of 1.4.6 it will always use 1.4.6. version 1.2.8 is also specified in my build.properties file as well.
My stack trace:
xxxxx#MC-N369748 topic-api % sbt
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
[info] welcome to sbt 1.4.6 (AdoptOpenJDK Java 1.8.0_275)
[info] loading project definition from /private/var/folders/hs/0vkhntfd557c8z8g8b_p7ly00000gp/T/hsperfdata_adu-tp01/project
[info] set current project to hsperfdata_adu-tp01 (in build file:/private/var/folders/hs/0vkhntfd557c8z8g8b_p7ly00000gp/T/hsperfdata_adu-tp01/)
[info] sbt server started at local:///Users/xxxxx/.sbt/1.0/server/143baa47709c908603e6/sock
[info] started sbt server
sbt:hsperfdata_xxxxx>
When we had this issue, it was caused by OS X restricting the permissions of the java executables. Since the process is not able to read/write to the current directory, sbt diverts to the tmp folder.
In System Preferences => Security & Privacy make sure the Full Disk Access property is turned on for the appropriate executables (probably java and javac in this case) or move your source code our of what OS X considers the protected part of the file system (we moved our builds from the user home directory to /code and sbt worked fine).
I'm not an expert with sbt so probably my question is a bit noob, but I've notice than when I create a project and download its dependencies with sbt, if I open the project with intellij, all the dependencies are redownloaded again, the same happen in the inverse orden intellij->sbt and also activator..
my (poor) knowledge about sbt is than this use ivy and the dependencies are downloaded in ~/.ivy2/ folder...that is where sbt is downloading my deps, but seems than intellij is using other folder.
personally I don't use so much activator, but I would like configure sbt and intellij for use the same ivy path...
2)recently I publish finagle-postgre to my local ivy using sbt +publishLocal, I can check in my ivy folder
/home/yo/.ivy2/local/com.twitter/finagle-postgres_2.11/0.1.0-SNAPSHOT
but unfortunately intellij is unable to resolve this dependency, I try adding this line to my build
resolvers += Resolver.file("Local", file( Path.userHome.absolutePath + "/.ivy2/local"))(Resolver.ivyStylePatterns)
but seems not works
3) the path where is downloaded the dependencies is related to which sbt-launch.jar file is used? How can I know what sbt-lauch.jar file is using sbt right now...
thanks guys!
If we're talking about IntelliJ appearing to download artifacts after they've already been downloaded by SBT/Activator, then it turns out that it's probably just that IntelliJ is downloading the sources - it's not redownloading the binary artifacts, just the source artifacts that accompany them.
This isn't readily apparent when you're looking at the Refreshing SBT project task in the Background Tasks popup, because the full download path is truncated, so you see something like this:
[info] downloading https://repo1.maven.org/maven2/org/apache/httpcompo...
..it's natural to assume that this is the same binary artifact you already saw SBT download on the console, but you can see the full story if you check the full log (go Help -> Show Log in files and open sbt.last.log in the file browser).
You'll see that the only artifacts getting downloaded end with -sources.jar:
$ grep repo1.maven.org /home/roberto/.IntelliJIdea2016.3/system/log/sbt.last.log
[info] downloading https://repo1.maven.org/maven2/org/apache/httpcomponents/httpclient/4.3.6/httpclient-4.3.6-sources.jar ...
[info] downloading https://repo1.maven.org/maven2/com/googlecode/javaewah/JavaEWAH/0.7.9/JavaEWAH-0.7.9-sources.jar ...
[info] downloading https://repo1.maven.org/maven2/org/pegdown/pegdown/1.2.1/pegdown-1.2.1-sources.jar ...
[info] downloading https://repo1.maven.org/maven2/commons-logging/commons-logging/1.1.3/commons-logging-1.1.3-sources.jar ...
```
If you don't have the Sources checkbox checked when you're doing Import project, these source downloads won't happen.
tested using IntelliJ 2016.3.5 and Scala plugin v2016.3.9
First, the activator is just a launcher for SBT itself, so there should be no difference in behaviour.
Second, IntelliJ also uses the files in ~/.ivy2 by default if you have not told it otherwise (by setting SBT_OPTS environment variable for example, but that depends on your IntelliJ version).
A difference might result if you're using different scala versions (e.g. 2.10.x vs. 2.11.x) when you do not have set the scalaVersion in your project explicitly. Then, each tool would download the corresponding libraries for the appropriate scala version it has configured by default.
Another thing is that IntelliJ will download source and javadoc jars for each dependency if you have enabled that in your settings which might look like it downloads the dependencies again.
Note, I'm wildly guessing here because you have not included any output of the programs you're using, so it's hard to say what the real problem is.
I am trying to follow the tutorial on compiling a simple DSL using Delite+LMS. I compiled LMS and Delite succesfully. Now, following this tutorial closely: http://stanford-ppl.github.io/Delite/myfirstdsl.html I run into problems when I try to build my profiling dsl. It seems that the compiler cannot find the delite-collection classes:
felix#felix-UX32VD:~/Documents/phd/delite/Delite$ sbt compile
Loading /home/felix/sbt/bin/sbt-launch-lib.bash
[info] Loading project definition from /home/felix/Documents/phd/delite/Delite/project
[info] Set current project to delite (in build file:/home/felix/Documents/phd/delite/Delite/)
[info] Compiling 5 Scala sources to /home/felix/Documents/phd/delite/Delite/dsls/profiling/target/scala-2.10/classes...
[error] /home/felix/Documents/phd/delite/Delite/dsls/profiling/src/example/profiling/Profile.scala:7: object DeliteCollection is not a member of package ppl.delite.framework.datastruct.scala
[error] import ppl.delite.framework.datastruct.scala.DeliteCollection
[error] ^
[error] /home/felix/Documents/phd/delite/Delite/dsls/profiling/src/example/profiling/Profile.scala:69: not found: type ScalaGenProfileArrayOps
[error] with ScalaGenDeliteOps with ScalaGenProfileOps with ScalaGenProfileArrayOps
[error]
^
Does someone have some insights to what I'm doing wrong?
From SBT manual:
Library dependencies can be added in two ways:
unmanaged dependencies are jars dropped into the lib directory
managed dependencies are configured in the build definition and downloaded
automatically from repositories (through Apache Ivy, exactly like Maven)
In any case, adding code inside a framework project is a bad idea, because you will have to change the build process (for example, adding an extra module). In addition, you might have to recompile all the code of the framework and this would be very slow.
The right way to make your code depending on a framework is:
Reference the library as a managed dependency available in some kind of repository (best solution).
Copy the jar inside the lib folder of your project and add it as an unmanaged dependency.
Since apparently Delite is not available on any Ivy repo, the best approach is to clone the Git repo and publish it locally. See http://www.scala-sbt.org/release/docs/Detailed-Topics/Publishing.html
Publishing Locally
The publishLocal command will publish to the local
Ivy repository. By default, this is in ${user.home}/.ivy2/local. Other
projects on the same machine can then list the project as a
dependency. For example, if the SBT project you are publishing has
configuration parameters like:
name := 'My Project'
organization := 'org.me'
version :=
'0.1-SNAPSHOT'
Then another project can depend on it:
libraryDependencies += "org.me" %% "my-project" % "0.1-SNAPSHOT"
I want to use the sbt-scrooge plugin, but its repo is unavailable now - http://koofr.github.com/.
I thought I'd include this plugin's source code directly in my own repo (as a git submodule).
I tried:
git submodule add https://github.com/bancek/sbt-scrooge.git project/sbt-scrooge
and added:
addSbtPlugin("net.koofr" % "sbt-scrooge" % "3.0.45")
to project/plugins.sbt. But it doesn't work - the following exception is thrown:
sbt.ResolveException: unresolved dependency: net.koofr#sbt-scrooge;3.0.45: not found
What's the right way to do that?
I know that I could checkout sbt-scrooge to the local filesystem, then sbt publish-local, and add the local ivy2 repo to sbt as a resolver. But I just want to know whether there are other ways to do this.
As explained here you can puth this in your project/plugins.sbt:
lazy val root = project.in(file(".")).dependsOn(scroogePlugin)
lazy val scroogePlugin = file("sbt-scrooge")
Or simply (without creating a local submodule):
lazy val root = project.in(file(".")).dependsOn(scroogePlugin)
lazy val scroogePlugin = uri("https://github.com/bancek/sbt-scrooge.git")
If you want to use a plugin it has to be available to sbt (and somehow finds its place in your local repository so addSbtPlugin can eventually find it or the project (sub)project of your sbt project should have it on the classpath).
Be adviced that not all plugins should be an integral part of a sbt project. Quite the contrary - they can be used in a project, but that doesn't necessarily mean they should be referenced by any project-specific files (within the project's directory), e.g. plugins to generate IDE-specific files. These plugins should be part of the global configuration in ~/.sbt under plugins.
There's also the issue of version mismatch between plugins and sbt. In your case, sbt-scrooge supports 0.12.2 (see project/build.properties) that might be unusable in sbt 0.13+.
With that said, I think the "right way" in your case since the sbt-scrooge plugin seems no longer maintained is to fork the project and maintain yourself in your own repository. sbt 0.13.1 is already the latest version, and the plugin may not yet support it. When the plugin gets new life with your fork other developers might benefit from the resurrection, too and having the sources attached to another project would only hinder reusability.
The answer to a similar question has helped me to offer a working solution that works with sbt 0.12.2 and without cloning the git repository.
$ cat project/build.properties
sbt.version=0.12.2
$ cat project/project/SbtScroogePlugin.scala
import sbt._
object SbtScroogePlugin extends Build {
lazy val plugins = Project("plugins", file(".")) dependsOn sbtScroogePlugin
lazy val sbtScroogePlugin = uri("https://github.com/bancek/sbt-scrooge.git")
}
$ cat sbt-scrooge.sbt
import net.koofr.sbt._
seq(CompileThriftScrooge.newSettings: _*)
With the project files above, sbt should be able to use the tasks and settings of the sbt-scrooge plugin.
$ sbt
[info] Loading global plugins from /Users/jacek/.sbt/plugins
[info] Loading project definition from /Users/jacek/sandbox/tmp/sample-project/project/project
[info] Loading project definition from /Users/jacek/.sbt/staging/52a2b7ff1377492a32ff/project
[info] Loading project definition from /Users/jacek/sandbox/tmp/sample-project/project
[info] Set current project to default-fe8e50 (in build file:/Users/jacek/sandbox/tmp/sample-project/)
> about
[info] This is sbt 0.12.2
[info] The current project is {file:/Users/jacek/sandbox/tmp/sample-project/}default-fe8e50
[info] The current project is built against Scala 2.9.2
[info] Available Plugins: org.sbtidea.SbtIdeaPlugin, com.timushev.sbt.updates.UpdatesPlugin, net.koofr.sbt.CompileThriftScrooge
[info] sbt, sbt plugins, and build definitions are using Scala 2.9.2
> scrooge-version
[info] 3.0.43
For the other tasks and settings, write scrooge- and hit TAB.
> scrooge-[TAB]
scrooge-build-options scrooge-cache-folder scrooge-fetch scrooge-gen
scrooge-jar scrooge-name scrooge-thrift-external-source-folder scrooge-thrift-include-folders
scrooge-thrift-namespace-map scrooge-thrift-output-folder scrooge-thrift-source-folder scrooge-thrift-sources
scrooge-unpack-deps scrooge-version
I've got an sbt (Scala) project that currently pulls artifacts from the web. We'd like to move towards a corporate-standardized Nexus repository that would cache artifacts. From the Nexus documentation, I understand how to do that for Maven projects. But sbt obviously uses a different approach. (I understand Ivy is involved somehow, but I've never used it and don't understand how it works.)
How do I tell sbt and/or the underlying Ivy to use the corporate Nexus repository system for all dependencies? I'd like the answer to use some sort of project-level configuration file, so that new clones of our source repository will automatically use the proxy. (I.e., mucking about with per-user config files in a dot-directory is not viable.)
Thanks!
Step 1: Follow the instructions at Detailed Topics: Proxy Repositories, which I have summarised and added to below:
(If you are using Artifactory, you can skip this step.) Create an entirely separate Maven proxy repository (or group) on your corporate Maven repository, to proxy ivy-style repositories such as these two important ones:
http://repo.typesafe.com/typesafe/ivy-releases/
http://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/
This is needed because some repository managers cannot handle Ivy-style and Maven-style repositories being mixed together.
Create a file repositories, listing both your main corporate repository and any extra one that you created in step 1, in the format shown below:
[repositories]
my-maven-proxy-releases: http://repo.example.com/maven-releases/
my-ivy-proxy-releases: http://repo.example.com/ivy-releases/, [organization]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]
Either save that file in the .sbt directory inside your home directory, or specify it on the sbt command line:
sbt -Dsbt.repository.config=<path-to-your-repo-file>
Good news for those using older versions of sbt: Even though, in the sbt 0.12.0 launcher jar at least, the boot properties files for older sbt versions don't contain the required line (the one that mentions repository.config), it will still work for those versions of sbt if you edit those files to add the required line, and repackage them into the sbt 0.12.0 launcher jar! This is because the feature is implemented in the launcher, not in sbt itself. And the sbt 0.12.0 launcher is claimed to be able to launch all versions of sbt, right back to 0.7!
Step 2: To make sure external repositories are not being used, remove the default repositories from your resolvers. This can be done in one of two ways:
Add the command line option -Dsbt.override.build.repos=true mentioned on the Detailed Topics page above. This will cause the repositories you specified in the file to override any repositories specified in any of your sbt files. This might only work in sbt 0.12 and above, though - I haven't tried it yet.
Use fullResolvers := Seq( resolver(s) for your corporate maven repositories ) in your build files, instead of resolvers ++= or resolvers := or whatever you used to use.
OK, with some help from Mark Harrah on the sbt mailing list, I have an answer that works.
My build class now looks like the following (plus some other repos):
import sbt._
//By extending DefaultWebProject, we get Jetty support
class OurApplication(info: ProjectInfo) extends DefaultWebProject(info) {
// This skips adding the default repositories and only uses the ones you added
// explicitly. --Mark Harrah
override def repositories = Set("OurNexus" at "http://our.nexus.server:9001/nexus/content/groups/public/")
override def ivyRepositories = Seq(Resolver.defaultLocal(None)) ++ repositories
/* Squeryl */
val squeryl = "org.squeryl" % "squeryl_2.8.0.RC3" % "0.9.4beta5"
/* DATE4J */
val date4j = "hirondelle.date4j" % "date4j" % "1.0" from "http://www.date4j.net/date4j.jar"
// etc
}
Now, if I delete the Squeryl tree from my machine's .ivy2/cache directory, sbt tries to grab it from the Nexus tree with the appropriate URL. Problem solved!
All you need is to define a property file sbt.boot.properties which will allow you to:
redefine the ivy cache location (I need that because it would be otherwise part of our roaming Windows profile, which is severely limited in disk space in our shop. See Issue 74)
define any other Maven repo you want
C:\HOMEWARE\apps\sbt-0.74\sbt.boot.properties
[scala]
version: 2.7.7
# classifiers: sources, javadoc
[app]
org: org.scala-tools.sbt
name: sbt
version: read(sbt.version)
class: sbt.xMain
components: xsbti
cross-versioned: true
classifiers: sources, javadoc
[repositories]
local
my-nexus: http://my.nexus/nexus/content/repositories/scala-tools/, [organization]/[module]/[revision]/[type]s/[artifact](-[classifier]).[ext]
maven-local
# sbt-db: http://databinder.net/repo/, [organization]/[module]/[revision]/[type]s/[artifact](-[classifier]).[ext]
# maven-central
# scala-tools-releases
# scala-tools-snapshots
[boot]
directory: project/boot
properties: project/build.properties
prompt-create: Project does not exist, create new project?
prompt-fill: true
quick-option: true
[log]
level: debug
[app-properties]
project.name: quick=set(test), new=prompt(Name)[p], fill=prompt(Name)
project.organization: new=prompt(Organization)[org.vonc]
project.version: quick=set(1.0), new=prompt(Version)[1.0], fill=prompt(Version)[1.0]
build.scala.versions: quick=set(2.8.0.RC2), new=prompt(Scala version)[2.8.0.RC2], fill=prompt(Scala version)[2.8.0.RC2]
sbt.version: quick=set(0.7.4), new=prompt(sbt version)[0.7.4], fill=prompt(sbt version)[0.7.4]
project.scratch: quick=set(true)
project.initialize: quick=set(true), new=set(true)
[ivy]
cache-directory: C:\HOMEWARE\projects\.ivy2\cache
Note: this sbt.boot.properties file is inspired from:
the one mentioned in the "Generalized Launcher" page of the sbt project.
the one found within sbt-0.74 itself!
I have commented any external Maven repository definition, and added a reference to my own Nexus Maven repo.
The launcher may be configured in one of the following ways in increasing order of precedence:
Replace the /sbt/sbt.boot.properties file in the jar.
Put a configuration file named sbt.boot.properties on the classpath. Put it in the classpath root without the /sbt prefix.
Specify the location of an alternate configuration on the command line. This can be done by:
either specifying the location as the system property sbt.boot.properties
or as the first argument to the launcher prefixed by '#'.
The system property has lower precedence.
Resolution of a relative path is:
first attempted against the current working directory,
then against the user's home directory,
and then against the directory containing the launcher jar.
An error is generated if none of these attempts succeed.
Define a sbt.bat wrapper (in order to be sure to specify your sbt.boot.properties) like:
C:\HOMEWARE>more C:\HOMEWARE\bin\sbt.BAT
#echo off
set t=%~dp0
set adp0=%t:C:\="%"
set SBT_DIR=%adp0%..\apps\sbt-0.74
dir C:\%SBT_DIR%\sbt-launch-0.7.4.jar
# if needed, add your proxy settings
set PROXY_OPTIONS=-Dhttp.proxyHost=my.proxy -Dhttp.proxyPort=80xx -Dhttp.proxyUser=auser -Dhttp.proxyPassword=yyyy
set JAVA_OPTIONS=-XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=256m -Xmx512M -cp C:\HOMEWARE\apps\sbt-0.74\sbt-launch-0.7.4
set SBT_BOOT_PROPERTIES=-Dsbt.boot.properties="sbt.boot.properties"
cmd /C C:\HOMEWARE\apps\jdk4eclipse\bin\java.exe %PROXY_OPTIONS% %JAVA_OPTIONS% %SBT_BOOT_PROPERTIES% -jar C:\HOMEWARE\apps\sbt-0.74\sbt-launch-0.7.4.jar %*
And your sbt will download artifacts only from:
your Nexus
your local Maven repo.
Just tested at home with an old Nexus opensource 1.6 I had running, java 1.6, sbt07.4
C:\Prog\Java\jdk1.6.0_18\jre\bin\java -Xmx512M -Dsbt.boot.properties=sbt.boot.properties - jar "c:\Prog\Scala\sbt\sbt-launch-0.7.4.jar"
That gives:
[success] Build completed successfully.
C:\Prog\Scala\tests\pp>sbt
Getting Scala 2.8.0 ...
downloading http://localhost:8081/nexus/content/repositories/scala/org/scala-lang/scala-compiler/2.8.0/scala-compiler-2.
8.0.jar ...
[SUCCESSFUL ] org.scala-lang#scala-compiler;2.8.0!scala-compiler.jar (311ms)
downloading http://localhost:8081/nexus/content/repositories/scala/org/scala-lang/scala-library/2.8.0/scala-library-2.8.
0.jar ...
[SUCCESSFUL ] org.scala-lang#scala-library;2.8.0!scala-library.jar (185ms)
:: retrieving :: org.scala-tools.sbt#boot-scala
confs: [default]
2 artifacts copied, 0 already retrieved (14484kB/167ms)
[info] Building project test 0.1 against Scala 2.8.0
[info] using sbt.DefaultProject with sbt 0.7.4 and Scala 2.7.7
If I try a funny value in the sbt.boot.properties file:
C:\Prog\Scala\tests\pp>sbt
Getting Scala 2.9.7 ...
:: problems summary ::
:::: WARNINGS
module not found: org.scala-lang#scala-compiler;2.9.7
==== nexus: tried
http://localhost:8081/nexus/content/repositories/scala/org/scala-lang/scala-compiler/2.9.7/scala-compiler-2.9.7.pom
-- artifact org.scala-lang#scala-compiler;2.9.7!scala-compiler.jar:
http://localhost:8081/nexus/content/repositories/scala/org/scala-lang/scala-compiler/2.9.7/scala-compiler-2.9.7.jar
So it does limit itself to the two repo I defined:
[repositories]
nexus: http://localhost:8081/nexus/content/repositories/scala
nexus2: http://localhost:8081/nexus/content/repositories/scala, [organization]/[module]/[revision]/[type]s/[artifact](-[classifier]).[ext]
(I commented everything else: local, maven-local, ...)
If I comment all repositories and put a funny value (2.7.9) for the scala version in the sbt.boot.properties, I do get (like the OP did)
C:\Prog\Scala\tests\pp>sbt
Error during sbt execution: No repositories defined.
If I put 2.7.7 (while still having all repo commented), yes, it won't generate an error:
C:\Prog\Scala\tests\pp>sbt
[info] Building project test 0.1 against Scala 2.8.0
[info] using sbt.DefaultProject with sbt 0.7.4 and Scala 2.7.7
But that's only because it already had downloaded scala2.8.0 during my previous tries.
If I remove that library from my project/boot directory, then it will throw an Exception:
[info] using sbt.DefaultProject with sbt 0.7.4 and Scala 2.7.7
> C:\Prog\Scala\tests\pp>sbt
Error during sbt execution: No repositories defined.
at xsbt.boot.Pre$.error(Pre.scala:18)
at xsbt.boot.Update.addResolvers(Update.scala:197)
...
at xsbt.boot.Boot$.main(Boot.scala:15)
at xsbt.boot.Boot.main(Boot.scala)
Error loading project: Error during sbt execution: No repositories defined.
edit the config file in sbt_home/conf "sbtconfig.txt"
add two line
-Dsbt.override.build.repos=true
-Dsbt.repository.config="C:/Program Files (x86)/sbt/conf/repo.properties"
the repo.properties content is
[repositories]
local
public: http://222.vvfox.com/public <-fix this ,write your local nexus group url
Well this has bugged me for a while so I found a guy that has written an SBT plugin for maven out on github called maven-sbt so all you have to do is include it in your plugins project and make your project mixin with maven.MavenDependencies and all your operations like update and publish-local work with your local maven. The nice thing about that is if you are like me, your org is all maven. So, all you libs are in you local maven repo but if for some reason you build with sbt first, then you start getting a bunch or jars in ivy too. What a waste of space, and time since you will still need to get them for your maven builds.
That said, I wish this were built into sbt so I would not need to add it to every project. Maybe as a processor at least. He mentioned in one thing I read that he would like to add it to 0.9 but I have not been able to find it.
I got this error because I had a blank file in ~/.sbt/repositories. Both adding repositories to the file and removing the file solved the problem.