I know if I add withSources when I define one dependency, sbt can download that sources jar file automatically.
For example,
val specs = "org.scala-tools.testing" % "specs_2.8.1" % "1.6.6" % "test" withSources ()
But for the scala-library.jar and scala-compiler.jar, I don't need define them explicitly, how can I get sbt download their sources for me? So, I don't need config it manually after generate idea project using sbt-idea-plugin.
You have to change the boot properties. There is a nice description in the recent blog decodified from Mathias:
"How to make SBT download scala library sources" (started from #hseeberger key starting points)
Here is the relevant part (in case that link ever goes stale)
First, forget about trying to find some “hidden” setting in your SBT project definition enabling Scala library source download! It does not exist (at least not in SBT version 0.7.x).
Rather, there are these two things you need to do in order to whip SBT into submission:
Create an alternative configuration file for your SBT launcher.
Make the SBT launcher use it.
These are the steps in detail:
Find your sbt-launcher-0.7.x.jar file.
Since I’m on OS/X and use SBT via Homebrew mine lives at /usr/local/Cellar/sbt/0.7.5.RC0/libexec/sbt-launch-0.7.5.RC0.jar.
Extract the sbt.boot.properties from the sbt sub directory in the launcher jar
Fire up your favorite editor and change line 3 to classifiers: sources (uncomment the line)
Find the sbt script file you created during your SBT setup (e.g. ~/bin/sbt, or, when using Homebrew, /usr/local/Cellar/sbt/0.7.x/bin/sbt)
Add the path to your tweaked sbt.boot.properties file, prepended with an ’#’ character and in double quotes, as the second-to-last argument of the java call.
This is what my sbt script file looks like:
#!/bin/sh
java -Xmx768M -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=256m \
-jar /usr/local/Cellar/sbt/0.7.5.RC0/libexec/sbt-launch-0.7.5.RC0.jar \
"#/usr/local/Cellar/sbt/0.7.5.RC0/libexec/sbt.boot.properties" \
"$#"
Once you have completed these steps SBT should happily download the scala-...-sources.jar files for the Scala compiler and standard library for any new project you create.
To have SBT do this for an existing project, you have to manually delete the project/boot/scala-{version} directory before performing an ‘sbt update’ (SBT does not fetch additional source artifacts if the main jar is already present).
Once you have a custom sbt.boot.properties file, there are also other ways to supply it to the SBT launcher.
See SO question "how do I get sbt to use a local maven proxy repository (Nexus)?"
Based on Michael Slinn comments:
If you are using sbt 0.11.x and above, use this command:
sbt update-sbt-classifiers
Two pieces of information.
(1) SBT Documentation
http://www.scala-sbt.org/0.13.5/docs/Detailed-Topics/Library-Management.html
and I quote:
"To obtain particular classifiers for all dependencies transitively, run the updateClassifiers task. By default, this resolves all artifacts with the sources or javadoc classifier."
This means you should not need to do anything, but you can make it explicit and put in you build.sbt:
transitiveClassifiers := Seq("sources", "javadoc")
To actually get the sources downloaded by SBT then you do:
"updateClassifiers"
(2) If you are working with Eclipse scala IDE - most likely you are as development of plugins for Eclipse/Netebeans is a lot more active for eclipse - then you should configure your ecplise to find out the sources if you do the following.
EclipseKeys.withSource := true
Here is the documentation you should read,
https://github.com/typesafehub/sbteclipse/wiki/Using-sbteclipse
Related
I have an sbt project that I have imported into Intellij. Sometimes I build the project at the command line using sbt, and then when I need to debug I build it from within Intellij. However, each time I alternate it requires a full rebuild when there is no need. Both build procedures output to the same class folder, namely .../target/scala-2.11/classes, so I don't understand why a full rebuild keeps happening?
As stated by CrazyCoder, intellij and sbt build have each their own tracking of changed files for incremental build. Thus each time one re-compile a file, the other treats it as a changed file and recompile it too.
While CrazyCoder's answer describes how to make them work on separated directory, by changing the sbt compiled classes dir. This answer explain how you can configure Intellij to use sbt for all build, thus only sbt does the compilation. This is a relatively new feature.
Just check the option:
file
> Settings
> Build, Execution, Deployment
> Build Tools
> SBT
> Use SBT shell for build and import
It works at least since intellij version 2017.2.3, and most probably it is an option from the SBT plugin.
For details about this feature, see jetbrains ticket: https://youtrack.jetbrains.com/issue/SCL-10984
IntelliJ IDEA cannot reuse the classes produced by the other build systems because it has its own incremental compiler which tracks the dependencies and builds the caches during the compilation so that it can compile only modified and dependent files when you make a change in the code. When you built with SBT/Maven/Gradle or command line javac, IntelliJ IDEA compiler cache doesn't know about what has changed and which files it should compile, therefore it performs the full rebuild.
A solution would be to use different output directories for IDE and SBT, this way IntelliJ IDEA will rebuild only files modified since the last build in the IDE and your command line SBT build will not trigger a rebuild in the IDE.
This configuration is performed using the sbt-ide-settings plug-in.
Add the following into plugins.sbt (or whatever files you configure the plugins in):
resolvers += Resolver.url("jetbrains-bintray",url("http://dl.bintray.com/jetbrains/sbt-plugins/"))(Resolver.ivyStylePatterns)
addSbtPlugin("org.jetbrains" % "sbt-ide-settings" % "0.1.2")
And here is how to customize the IDE output directory in build.sbt:
ideOutputDirectory in Compile := Some(new File("target/idea/classes"))
ideOutputDirectory in Test := Some(new File("target/idea/test-classes"))
Feel free to change the paths according to your needs.
I am trying to use scala to access Amazon's DynamoDB and found this great package on github https://github.com/piotrga/async-dynamo
so I downloaded the code as a zip file , unzipped it and then did "sbt clean test" and getting the following error
error sbt.ResolveException: unresolved dependency: asyncdynamo#async-dynamo;1.6.0: not found
Questions : is this the correct way to generate a jar file that I can include in my Scala program or is there a better way?
thanks in advance.
EDIT:
just for the benefit of others, the SCALA SBT documentation provides lots of information regarding the build process.
Instead of generating a jar file, you can just run 'sbt publish-local' and then include the lines for the managed dependency in the other project.
Sbt/ivy will see you have the artifact that way you don't need to add the jar to the other project which is much cleaner.
Then for example if you need to update the other project you don't need to replace the jar again - just publish-local again and clean and run your other project!
You are not the only one to have problems with this it seems, see github issues page:
https://github.com/piotrga/async-dynamo/issues
The command 'sbt clean test' will run the tests sbt detects. If you want a .jar file you could use 'sbt clean package', which produces a .jar in the target/ folder.
I cloned the repo and was able to run sbt package after changing release.sbt a bit. I had to change the 'publishTo'-variable as it seemed to depend on the repository creators local environment variable, so I just commented it away.
I did not get the dependency problem, so I suppose it is correctly declared. The tests it tries to run do fail though, but sbt package compiles produces the .jar just fine.
EDIT: As Matthias Schlaipfer pointed out in the comments, the more elegant way(and much easier) would just be to add this as an depency in your build.sbt. From the readme, this is what you need to add:
resolvers += "piotrga" at
"https://github.com/piotrga/piotrga.github.com/tree/master/maven-repo"
libraryDependencies += "asyncdynamo" % "async-dynamo" % "1.6"
(This is a follow up to sbt not creating projects correctly. The question wasn't answered.)
Basically, that question says "I don't know how to create a project under the new sbt. With the old one, I just ran sbt in a new folder and there was a guided wizard that led me through the setup."
The accepted answer does not explain how to create a new project, it just points to the documentation, which also doesn't explicitly say how to create a new project -- only how to write a build.sbt file.
So I tried first writing a build.sbt and then running sbt in the directory with the build.sbt file, but I still don't see a src directory to work with.
Could someone post a simple step-by-step (I'm assuming there are like 3 steps at most) guiding how to create a new project under sbt 0.10.X?
I found the answer I was looking for at this webpage: Scala 2.9.1, sbt 0.10 and ScalaTest step-by-step.
The high-level steps are:
mkdir my_project make a folder for your project
Create a simple my_project/build.sbt file, e.g.:
name := "A Project"
version := "0.1"
scalaVersion := "2.9.1"
libraryDependencies ++= Seq(
"org.scalatest" %% "scalatest" % "1.6.1" % "test"
)
Create a file my_project/src/main/scala/HelloWorld.scala, where you create all the directories you need as you go (e.g. create the directory structure src/main/scala/)
object Main extends App {
Console.println("Hello World!")
}
Execute your sbt commands: e.g. sbt run
I am surprised that noone gave another solution which is the closest to the old way (as mentioned by #dsg) to create a simple project in sbt:
Just run sbt in your project directory, then issue the following commands in the sbt REPL:
> set name := "MyProject"
> set version := "1.0"
> set scalaVersion := "2.9.0"
> session save
> exit
Granted, it is only mildly useful as it will just create the build.sbt file (enough to make it a proper sbt project) with the corresponding properties set, and you might as well create the file by hand (I usually prefer to do so myself). It won't create the src directory either.
Just a few days ago np (new project) plugin to sbt was released. It intended to dealt exactly with that problem:
Initial release. Provides a minimal interface for generating new sbt
projects via,... sbt.
Basic use is to install the plugin globally and start up a new project
with
$ sbt
$ np name:my-project org:com.mypackage version:0.1.0-SNAPSHOT
This will generate a simple build.sbt project for you along with the
standard project directory structure for main and test sources.
For more advanced usage, see the project's readme for more info
You can use https://github.com/n8han/giter8 to generate project layout using various templates
In newer versions of sbt, you can just install sbteclipse:
// ~/.sbt/plugins/build.sbt
addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.1.0")
then from sbt's console you can run:
eclipse with-source=true
In version 0.10.x I think this post can help you:
http://dcsobral.blogspot.fr/2011/06/very-quick-guide-to-project-creation-on.html
I've been using https://github.com/ymasory/sbt-prototype skeleton. See also my other answer.
It was the first one that just worked and I've been a quite happy with it since then.
Don't forget the recent sbt 0.13.3 new command:
Example:
First, you need sbt’s launcher version 0.13.13 or above.
Normally the exact version for the sbt launcher does not matter because it will use the version specified by sbt.version in project/build.properties; however for new sbt’s launcher 0.13.13 or above is required as the command functions without a project/build.properties present.
Next, run:
$ sbt new eed3si9n/hello.g8
....
name [hello]:
scala_version [2.11.8]:
Template applied in ./hello
This ran the template eed3si9n/hello.g8 using Giter8, prompted for values for “name” and “scala_version” (which have defaults “hello” and “2.11.8”, which we accepted hitting [Enter]), and created a build under ./hello.
Check out the GitHub repo Scala SBT Template. In particular the buildt.sbt file.
Just clone the repo, go to that directory, then call the sbt command.
$ git clone git://github.com/dph01/scala-sbt-template.git
$ cd scala-sbt-template
$ ./sbt
From inside of sbt, you can type run to execute provided code. Have fun!
An alternative way to generate the project structure using Intellij:
Create the directory for the project and include there a basic sbt file. You just need to specify the project name.
name := "porjectName"
With Intellij import the project. During the process check the options "Use auto-import" and "Create directories for empty content roots automatically"
That will create for you the basic skeleton for the sbt project.
I just got started with Scala/LiftWeb/Sbt developing, and I'd like to import a Sbt project in IntelliJ Idea.
Actually, I managed to import my project in two different ways:
1) with Maven. I created a Maven project, and of top of that I created a Sbt project, which I then imported in IntelliJ. I could then easily start, stop the jetty server, and do other stuff.
But that's not what I want. I want to do the same stuff, just Maven-free.
That lead me to
2) with Eclipse. So, I created a new Sbt project (with a little script I wrote, configuring the Sbt project to be a WebProject). I used then the sbt-eclipsify plugin to 'convert' the project for Eclipse, which I then imported in IntelliJ (existing source -> eclipse).
But the problems started here: I cannot get the IntelliJ Sbt plugin to work.
Can anyone help me with this?
There are three basic ways how to create a project - modern versions of IntelliJ can import sbt project out of the box, otherwise you can either use sbt plugin to generate IntelliJ project, or use IntelliJ Scala plugin to create sbt project. Basic features work out of the box using both solutions, some complex builds can have problems, so try other tools to see if it works there.
IntelliJ
IntelliJ IDEA has become so much better these days. The current version (14.0.2) supports sbt projects out of the box with the Scala plugin. Just install the plugin and you should be able to open up Scala/sbt projects without any troubles.
With the plugin, just point at a sbt project and IDEA is going to offer you a wizard to open that kind of project.
IntelliJ Scala Plugin
IntelliJ plugin can be found here
http://confluence.jetbrains.com/display/SCA/Scala+Plugin+for+IntelliJ+IDEA or can be installed directoly from within the IDE using Settings -> Plugins dialog. Afterwards one can just do File -> New Project -> Scala -> SBT based. IntelliJ will generate basic build.sbt, download necessary dependencies and open project.
SBT Plugin
Sbt plugin that generate an idea project based on the sbt files can be found here: https://github.com/mpeltonen/sbt-idea
SBT 12.0+ & 13.0+
Simply add addSbtPlugin("com.github.mpeltonen" % "sbt-idea" % "1.5.2") to your build.sbt; no additional resolvers are needed.
Older Versions:
SBT 0.11+
Create and add the following lines to ~/.sbt/plugins/build.sbt OR PROJECT_DIR/project/plugins.sbt
resolvers += "sbt-idea-repo" at "http://mpeltonen.github.com/maven/"
addSbtPlugin("com.github.mpeltonen" % "sbt-idea" % "1.6.0")
Use gen-idea in sbt to create IDEA project files.
By default, classifiers (i.e. sources and javadocs) of sbt and library dependencies are loaded if found and references added to IDEA project files. If you don't want to download/reference them, use command gen-idea no-classifiers no-sbt-classifiers.
SBT 0.10.1
(according to the plugin author, 0.10.0 won't work!)
Create and add the following lines to ~/.sbt/plugins/build.sbt:
resolvers += "sbt-idea-repo" at "http://mpeltonen.github.com/maven/"
libraryDependencies += "com.github.mpeltonen" %% "sbt-idea" % "0.10.0"
Use gen-idea sbt task to create IDEA project files.
By default, classifiers (i.e. sources and javadocs) of sbt and library dependencies are loaded if found and references added to IDEA project files. If you don't want to download/reference them, use command gen-idea no-classifiers no-sbt-classifiers.
SBT 0.7
To use it, simply run this from your sbt shell, it will use the plugin as an external program:
> *sbtIdeaRepo at http://mpeltonen.github.com/maven/
> *idea is com.github.mpeltonen sbt-idea-processor 0.4.0
...
> update
...
> idea
...
You can also add trait in your project definition, as you want:
import sbt._
class MyProject(info: ProjectInfo) extends ParentProject(info) with IdeaProject {
lazy val mySubProject = project("my-subproject", "my-subproject", new DefaultProject(_) with IdeaProject)
// ...
}
For now I do this by hand. It is quite simple.
Create the project with SBT
Create a new IDEA Project with the same root path
Create a module with the same root path
Set src/main/scala as a src path on the module
Set src/test/scala as a test path on the module
Add scala-library.jar as a library
Add lib (if it is present) as a jar directory within a module library
Add lib_managed/compile (if it is present) as a jar directory within a module library
Add lib_managed/test (if it is present) as a jar directory within a module library
That's it from memory. It would be better if it were automated, but it's no big deal as it is now.
One note of caution: The above approach doesn't work well with new-school sbt, i.e. versions 0.10 and newer, because it doesn't copy dependencies into lib_managed by default. You can add
retrieveManaged := true
to your build.sbt to make it copy the dependencies into lib_managed.
Tempus fugit and IntelliJ IDEA has become so much better these days. It's 2015 after all, isn't it?
Having said that, the latest version of IntelliJ IDEA 14.0.2 supports sbt projects out of the box with the Scala plugin. Just install the plugin and you should be able to open up Scala/sbt projects without much troubles.
I'm using the Early Access version of the plugin which is 1.2.67.6.EAP as of the time of the writing.
With the plugin just point at a sbt project and IDEA is going to offer you a wizard to open that kind of project.
About sbt-idea in sbt 0.12.4
For sbt 0.12.4 the system-wide plugin configuration file - ~/.sbt/plugins/build.sbt or PROJECT_DIR/project/plugins.sbt - should have the following lines:
resolvers += "Sonatype snapshots" at "http://oss.sonatype.org/content/repositories/snapshots/"
addSbtPlugin(dependency="com.github.mpeltonen" % "sbt-idea" % "1.5.0-SNAPSHOT")
Run sbt gen-idea to generate IDEA project files.
Read the sbt-idea plugin website for more up-to-date information. You may also find my blog entry Importing sbt-based project to IntelliJ IDEA 13 (with sbt-idea, Scala 2.11 and sbt 0.12) useful.
For sbt 0.7
See the answer elsewhere on this page.
For sbt 0.10
Clone and build Ismael's sbt-idea:
git clone https://github.com/ijuma/sbt-idea.git
cd sbt-idea
git checkout sbt-0.10
./sbt package
Create an sbt plugin lib directory if you don't have one already
mkdir -p ~/.sbt/plugins/lib
Copy the jar built in step one into here
cp sbt-idea/target/scala-2.8.1.final/*.jar ~/.sbt/plugins/lib
Restart or reload sbt, then you can run gen-idea (or gen-idea with-classifiers if you want sources and javadoc in intelliJ too)
Source: Tackers' suggestion on the message group.
In IntelliJ IDEA 13.x itself
You can open an SBT-based project in IDEA nowadays. It will create the necessary project and modules, and keep your dependencies up-to-date whenever you make changes to the build scripts.
I just went through all this pain. I spend days trying to get an acceptable environment up and have come to the conclusion that ENSIME, SBT and JRebel are going to be my development environment for some time. Yes, it is going back to Emacs, but ENSIME turns it into a bit or an idea with refactoring, debugging support, navigation, etc. It's not nowhere near as good as Eclipse (Java), but unless the scala plugins work better it's the best we have.
Until the Scala development environments get up to snuff (Eclipse or IntelliJ) I'm not going to bother. They're just way too buggy.
See the discussion on the lift site.
http://groups.google.com/group/liftweb/browse_thread/thread/6e38ae7396575052#
Within that thread, there is a link to a HOWTO for IntelliJ, but although it kinda works, there are many issues that render it a little less that useful.
http://blog.morroni.com/2010/07/14/setup-intellij-9-for-lift-framework-development/comment-page-1/
The answers are old for 2014.
In IntelliJ 13.x, the plugin Scala is ver 0.41.2 ( SBT is included).
My SBT version is 0.13.5 (terminal : sbt sbtVersion )
Go to the project's root folder and enter in the terminal
sbt idea
You will see two new hidden folders .idea and .idea_modules.
Then in IntelliJ, File > Open > select the project.
It should open the project without any problem.
Before you start creating your SBT project, make sure that the Scala plugin is downloaded and enabled in IntelliJ IDEA.
below link explains everything you need to know.
https://www.jetbrains.com/help/idea/2016.1/getting-started-with-sbt.html
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.