Why doesn't sbt create project files? - sbt

I have tried to install SBT on my macbook. When I run it, it doesn't ask me for any project definitions (e.g. title) and simply says
[info] Set current project to default (in build file:/Users/qui/Documents/Programming/test2/)
It then goes to what looks like the sbt interpreter.
When I look inside "test2", there is a project and target directory but I dont see a src directory to work with
Clearly I have gone wrong somewhere in my installation but I'm unsure where. Any ideas?
Update
So I just installed 0.10 on a fresh fedora install. And I am getting the exact same problem, same "info" message and it has only created a project and target directory
I must be doing something idiotic right? What am I doing wrong? :p

I work with SBT 0.13 so...your mileage may vary.
sbt's default behaviour
What you experience is the default behaviour of sbt. The tool expects that the project files are already in place or when there is no project files it doesn't bother to create them - the default values are just applied to the current directory that effectively becomes the project directory for a project called by the name of the directory it's in. SBT then opens sbt shell.
jacek:~/sandbox/stackoverflow/testaaa
$ tree
.
0 directories, 0 files
jacek:~/sandbox/stackoverflow/testaaa
$ sbt
[info] Loading global plugins from /Users/jacek/.sbt/0.13/plugins
[info] Updating {file:/Users/jacek/.sbt/0.13/plugins/}global-plugins...
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
[info] Set current project to testaaa (in build file:/Users/jacek/sandbox/stackoverflow/testaaa/)
[testaaa]>
Quoting Running from the official documentation of SBT.
Running sbt with no command line arguments starts it in interactive
mode. Interactive mode has a command prompt (with tab completion and
history!).
Example
In your case, when you started sbt in /Users/qui/Documents/Programming/test2/ it silently assumed it's the project directory and applied the default settings.
The following sbt session is in test2 directory, too. I use help to display the help of a setting key and then use the key to display its value.
jacek:~/sandbox/stackoverflow/test2
$ tree
.
0 directories, 0 files
jacek:~/sandbox/stackoverflow/test2
$ sbt
[info] Loading global plugins from /Users/jacek/.sbt/0.13/plugins
[info] Set current project to test2 (in build file:/Users/jacek/sandbox/stackoverflow/test2/)
[test2]> help name
Project name.
[test2]> name
[info] test2
[test2]> help organization
Organization/group ID.
[test2]> organization
[info] default
[test2]> help version
The version/revision of the current module.
[test2]> version
[info] 0.1-SNAPSHOT
[test2]> help scalaVersion
The version of Scala used for building.
[test2]> scalaVersion
[info] 2.10.2
(I've changed the prompt so the name of the project, i.e. the name of the directory sbt has been started in, is displayed before the >).
You can change the value of a key with the set command that Evaluates a Setting and applies it to the current project.
[test2]> help set
set [every] <setting-expression>
Applies the given setting to the current project:
1) Constructs the expression provided as an argument by compiling and loading it.
2) Appends the new setting to the current project's settings.
3) Re-evaluates the build's settings.
This command does not rebuild the build definitions, plugins, or configurations.
It does not automatically persist the setting(s) either.
To persist the setting(s), run 'session save' or 'session save-all'.
If 'every' is specified, the setting is evaluated in the current context
and the resulting value is used in every scope. This overrides the value
bound to the key everywhere.
[test2]> set scalaVersion := "2.10.3"
[info] Defining *:scalaVersion
[info] The new value will be used by *:allDependencies, *:dependencyUpdatesData and 11 others.
[info] Run `last` for details.
[info] Reapplying settings...
[info] Set current project to test2 (in build file:/Users/jacek/sandbox/stackoverflow/test2/)
[test2]> scalaVersion
[info] 2.10.3
In the other question on StackOverflow #regis-jean-gilles has showed how to set the other settings using the set command.
[test2]> set name := "My test2 sbt project"
[info] Defining *:name
[info] The new value will be used by *:description, *:normalizedName and 8 others.
[info] Run `last` for details.
[info] Reapplying settings...
[info] Set current project to My test2 sbt project (in build file:/Users/jacek/sandbox/stackoverflow/test2/)
[test2]> set version := "1.0"
[info] Defining *:version
[info] The new value will be used by *:isSnapshot, *:projectId and 5 others.
[info] Run `last` for details.
[info] Reapplying settings...
[info] Set current project to My test2 sbt project (in build file:/Users/jacek/sandbox/stackoverflow/test2/)
[test2]> set scalaVersion := "2.10.3"
[info] Defining *:scalaVersion
[info] The new value will be used by *:allDependencies, *:dependencyUpdatesData and 11 others.
[info] Run `last` for details.
[info] Reapplying settings...
[info] Set current project to My test2 sbt project (in build file:/Users/jacek/sandbox/stackoverflow/test2/)
[test2]> session save
[info] Reapplying settings...
[info] Set current project to My test2 sbt project (in build file:/Users/jacek/sandbox/stackoverflow/test2/)
[test2]> exit
The build.sbt file will then contain all the settings as if there'd been set there in the first place.
$ cat build.sbt
name := "My test2 sbt project"
version := "1.0"
scalaVersion := "2.10.3"
By default, sbt creates various files in target directory. When you look inside the target directory, there are no files - just an empty directory. The same applies to project that also may or may not hold target directory. They're assumed to be available and if there's not, they're created by default.
When you change a setting in sbt's interactive shell (with set), you can save the session with session save.
[test2]> help session
session <command>
Manipulates session settings, which are temporary settings that do not persist past the current sbt execution (that is, the current session).
Valid commands are:
clear, clear-all
Removes temporary settings added using 'set' and re-evaluates all settings.
For 'clear', only the settings defined for the current project are cleared.
For 'clear-all', all settings in all projects are cleared.
list, list-all
Prints a numbered list of session settings defined.
The numbers may be used to remove individual settings or ranges of settings using 'remove'.
For 'list', only the settings for the current project are printed.
For 'list-all', all settings in all projets are printed.
remove <range-spec>
<range-spec> is a comma-separated list of individual numbers or ranges of numbers.
For example, 'remove 1,3,5-7'.
The temporary settings at the given indices for the current project are removed and all settings are re-evaluated.
Use the 'list' command to see a numbered list of settings for the current project.
save, save-all
Makes the session settings permanent by writing them to a '.sbt' configuration file.
For 'save', only the current project's settings are saved (the settings for other projects are left alone).
For 'save-all', the session settings are saved for all projects.
The session settings defined for a project are appended to the first '.sbt' configuration file in that project.
If no '.sbt' configuration file exists, the settings are written to 'build.sbt' in the project's base directory.
[test2]> session save
[info] Reapplying settings...
[info] Set current project to test2 (in build file:/Users/jacek/sandbox/stackoverflow/test2/)
Once you do that, a build.sbt with your own setting(s) is saved. That might be a good starting point for further configuration of a project.
jacek:~/sandbox/stackoverflow/test2
$ cat build.sbt
scalaVersion := "2.10.3"
Typesafe Activator
According to the home page of Typesafe Activator:
Typesafe Activator is a browser-based or command-line tool that helps
developers get started with the Typesafe Reactive Platform.
Under the covers, Activator is a UI built atop of sbt as demo'ed by Josh Suereth in the screencast Introducing sbt 0.13.2.
It appears that that's the only blessed solution for setting up sbt projects out of the many templates available in Activator.
giter8 - sbt project (layout) templates
If you however need some help to lay out the directory structure and have a ready-to-use project setup, you may want to use giter8 that's a command line tool to apply templates defined on github
Say, you want to create a project with scalaz dependency. You may want to use adinapoli/scalaz-revolver (see the list of available templates).
jacek:~/sandbox/stackoverflow
$ g8 adinapoli/scalaz-revolver
Simple scala project with sbt-revolver
organization [org.example]: pl.japila
name [Scala sbt-revolver project]:
scala_version [2.9.2]: 2.10.3
version [0.1-SNAPSHOT]:
Template applied in ./scala-sbt-revolver-project
jacek:~/sandbox/stackoverflow
$ cd scala-sbt-revolver-project/
jacek:~/sandbox/stackoverflow/scala-sbt-revolver-project
$ tree
.
├── README
├── build.sbt
├── project
│   ├── Build.scala
│   ├── build.properties
│   └── plugins.sbt
└── src
└── main
└── scala
└── pl
└── japila
└── ScalaSbtrevolverProject.scala
6 directories, 6 files
See Create a project directory with source code to find out more.
np - new sbt project generation made simple(r)
As pointed out in the comments by #0__ below, there's another project that aims at simplifying how new projects in sbt are created - np. That seems exactly what you needed.
In https://github.com/softprops/np#for-sbt-013 there's a complete description of what's needed to set it up and create new sbt projects using the utility that boils down to:
Registering the sbt plugin. Add the following to ~/.sbt/0.13/plugins/np.sbt.
addSbtPlugin("me.lessis" % "np" % "0.2.0")
Define a custom global overrides in ~/.sbt/0.13/np.sbt. Add the following to the file.
seq(npSettings:_*)
(NpKeys.defaults in (Compile, NpKeys.np)) ~= {
_.copy(org="me.lessis", version="0.1.0-SNAPSHOT")
}
Use the np plugin's command - np. Create an empty directory for the sbt project and run sbt np.
jacek:~/sandbox/stackoverflow
$ mkdir np-sandbox/
jacek:~/sandbox/stackoverflow
$ cd np-sandbox/
jacek:~/sandbox/stackoverflow/np-sandbox
$ sbt np
[info] Loading global plugins from /Users/jacek/.sbt/0.13/plugins
[info] Set current project to np-sandbox (in build file:/Users/jacek/sandbox/stackoverflow/np-sandbox/)
[info] Generated build file
[info] Generated source directories
[success] Total time: 0 s, completed Dec 7, 2013 12:51:42 PM
jacek:~/sandbox/stackoverflow/np-sandbox
$ tree
.
├── build.sbt
├── src
│   ├── main
│   │   ├── resources
│   │   └── scala
│   └── test
│   ├── resources
│   └── scala
└── target
└── streams
└── compile
└── np
└── $global
└── out
12 directories, 2 files
jacek:~/sandbox/stackoverflow/np-sandbox
$ cat build.sbt
organization := "me.lessis"
name := "default"
version := "0.1.0-SNAPSHOT"

No you're not doing something wrong, previous versions of sbt (0.7.x) did ask you if you wanted to create your project.
sbt version 0.10.x is a complete rewrite and does not act the same way (i.e. ask you to create a project on startup).
The old project was on googlecode but has since moved to github, you can find the documentation for 0.10.x at https://github.com/harrah/xsbt/wiki, in particular https://github.com/harrah/xsbt/wiki/Settings if you come from a 0.7.x background.
It's a bit hard to wrap your head around the new settings system at first, but trust me when I say you'll love it :)

As described in the np plugin readme, the required steps would be :
mkdir -p src/{main,test}/scala
touch build.sbt && vi build.sbt # fill in the basics (name, organization, version)
touch README.md && vi README.md
sbt
... start coding

One-liner to create the directory-structure and files (all empty):
mkdir -p ./src/{main,test}/{scala,java,resources}; mkdir project; touch build.sbt; touch project/build.properties

I found and updated a script by Alvin Alexander (author of the amazing book Scala Cookbook) that does just what you want.
Once again, I provide a bash script because the task of creating the directories and the files is pedantic, but simple. Making a full fledged plugin for SBT for this is an overkill.
This script creates an SBT project directory beneath the current directory.
Directory/Project Name (MyFirstProject): ProjectX
Create .gitignore File? (Y/n):
Create README.md File? (Y/n):
-----------------------------------------------
Directory/Project Name: ProjectX
Create .gitignore File?: y
Create README.md File?: y
-----------------------------------------------
Create Project? (Y/n):
Project created. See the following URL for build.sbt examples:
http://alvinalexander.com/scala/sbt-syntax-examples
$ cat build.sbt
name := "ProjectX"
version := "1.0"
scalaVersion := "2.11.7"
$
And finally, I believe SBT launched without any arguments should behave exactly like this script.

Related

sbt plugins isn't picked up from submodules?

I'm trying to convert a single module project into two modules with a
root aggregate. Feels like a normal thing to do.
So, to simplify I have removed the second project that I added, but I
do something like:
cd myproject
mkdir core
mv * core
and then add a build.sbt in myproject like
lazy val root = project.in( file(".") ).aggregate(core)
lazy val core = project in file("core")
However, trying to build core I get:
[myproject]/core/build.sbt:22: error: not found: value lessSettings
seq(lessSettings:_*)
which is the settings for a plugin added in project/plugins.sbt of the
original project now in
[myproject]/core/project/plugins.sbt
How come this is not picked up? Can't I have plugins living only in
submodules? cd:ing into core submodule and running sbt it works just fine. Do I have
to move my plugins to root/project? Pretty please, it can't be so?
Your plugin.sbt file is ignored because you cannot have a project subfolder in a sub-project of a multi-project build.
In a multi-project build,
The .sbt files of the root project, and all .sbt files of all sub-projects, are all part of a single build definition. The settings defined in a sub-project are just automatically scoped to that project.
Since there is only one build definition, there is only one project to build that build definition, and that is in the project/ folder of the root project. All project/ folders of sub-projects will be ignored.
In your case, moving your plugin.sbt to the build root project folder should make your plugin appear again.
Furthermore, if you only work on the core project, instead of running sbt in core, you can run sbt in the root project and type project core to "move" (actually, scope everything you do) to the core sub-project.

Need advice on project layout for Play 2.2 submodule with other modules as dependencies

I have an existing SBT project with modules. I want to add Play 2.2 into my project as a submodule. This new Play module will depend on other modules.
What I found so far was mostly about Play being the main project with supporting modules. If Play does support this setup, please point me in the right direction how to do it. Thanks.
My intended setup (simplified):
my_project
\--- desktop_ui
\--- src/main
\--- src/test
\--- common
\--- src/main
\--- src/test
\--- web_ui (Play framework)
\--- app/controllers
\--- app/views
\--- app/models
\--- conf
Play 2.2 supports sbt 0.13 so to use it for your expected project layout I'd recommend to have the following build.sbt in the my_project root project:
import play.Project._
lazy val my_project = project in file(".") aggregate (desktop_ui, common, web_ui)
lazy val desktop_ui = project dependsOn common
lazy val common = project
// no need to dependsOn "common" since it's already a dependency of "desktop_ui"
lazy val web_ui = play.Project(name = "web_ui", path = file("web_ui"))
.dependsOn(desktop_ui)
Since my_project uses Play 2.2 class - play.Project - to define a Play project, project/plugins.sbt is required.
resolvers += "Typesafe repository" at "http://repo.typesafe.com/typesafe/releases/"
addSbtPlugin("com.typesafe.play" % "sbt-plugin" % "2.2.2-RC1")
That might explain why Play module is usually a top-level one (since so much is needed in the top-level project that it effectively becomes a Play module).
The complete project layout is as follows:
$ tree
.
├── build.sbt
└── project
├── build.properties
└── plugins.sbt
1 directory, 3 files
What's quite interesting is that even without all the project directories and no Play project in place (just a definition in the build.sbt) you can still run the web_ui project and access it with your web browser (!) It will fail for obvious reasons, but shows there's not much needed to get running with sbt and Play.
$ sbt
[info] Loading global plugins from /Users/jacek/.sbt/0.13/plugins
[info] Loading project definition from /Users/jacek/sandbox/so/play-2.2-multi/my_project/project
[info] Updating {file:/Users/jacek/sandbox/so/play-2.2-multi/my_project/project/}my_project-build...
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
[info] Set current project to my_project (in build file:/Users/jacek/sandbox/so/play-2.2-multi/my_project/)
[my_project]> projects
[info] In file:/Users/jacek/sandbox/so/play-2.2-multi/my_project/
[info] common
[info] desktop_ui
[info] * my_project
[info] web_ui
[my_project]> project web_ui
[info] Set current project to web_ui (in build file:/Users/jacek/sandbox/so/play-2.2-multi/my_project/)
[web_ui]> run
[info] Updating {file:/Users/jacek/sandbox/so/play-2.2-multi/my_project/}common...
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
[info] Updating {file:/Users/jacek/sandbox/so/play-2.2-multi/my_project/}desktop_ui...
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
[info] Updating {file:/Users/jacek/sandbox/so/play-2.2-multi/my_project/}web_ui...
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
--- (Running the application from SBT, auto-reloading is enabled) ---
[info] play - Listening for HTTP on /0:0:0:0:0:0:0:0:9000
(Server started, use Ctrl+D to stop and go back to the console...)
[info] play - Application started (Dev)
Two options:
1) have an 'empty' main project aggregating your 3 sub-projects:
root
\--- project
\--- Build.scala
\--- web_ui
\--- common
\--- desktop_ui
And in Build.scala something like this:
lazy val common = Project(id = "common", base = file("common"))
lazy val desktopUi = Project(id = "desktop_ui", base = file("desktop_ui")
lazy val webUi = play.Project(name = "web_ui", path = file("web_ui"))
.dependsOn(common, desktopUi)
lazy val root = Project(id = "root", base = file(".")).aggregate(common, desktopUi, webUi)
With this option, you can start sbt from the root folder and build all your projects. You also define all the settings, dependencies in this unique build definition.
2) Another layout can be used to keep your sub-projects independent from each other. I tend to prefer this way because it's cleaner (e.g. I can work on common as an independent project, not as a submodule) but it is not as convenient to build the whole system.
root
\--- web_ui
\--- project
\--- Build.scala
\--- common
\--- project
\--- Build.scala
\--- desktop_ui
\--- project
\--- Build.scala
Here, each project is independent (you can use build.sbt instead of Build.scala if you want, see sbt documentation) and in web_ui/project/Build.scala :
lazy val common = RootProject(file("../common"))
lazy val desktopUi = RootProject(file("../desktop_ui"))
val main = play.Project(name = "web_ui", path = file("web_ui")).dependsOn(common, desktopUi)
Here, root is just used to gather everything in one folder, then the play project references the other modules.

Copying files using SBT

I am using SBT for building a java project and have a requirement of copying text files (that are not resources, but used by java classes to read instead).
I am inexperienced with either SBT or Scala (needed for build.scala file)
Any help would be really appreciated.
For example, if my directory structure is:
test
|- files
|- one.text
|- main
|- java
|- Test.java
I want the one.text file available as well in the target folder once I execute an sbt goal like
sbt test
Following lines in your build.sbt should do the trick:
unmanagedResourceDirectories in Test <+= (baseDirectory) {_ / "files"}
unmanagedSourceDirectories in Test <+= (baseDirectory) {_ / "main" / "java"}
You have a non standard project layout though. If you can change it to a standard "maven style":
project/src/main/java
project/src/main/resources
project/src/test/java/{Test.java, ...}
project/src/test/resources/{one.text, ...}
sbt will do resource copying automatically.

How to publish jar to local repository?

I have a library compiled to a jar (not an sbt project, no source code, just the jar file) that's not available on a repository.
Is there a way to publish the jar locally so I can add the dependency using the libraryDependencies += "org.xxx" % "xxx" % "1.0" notation? (I already know how to add the file to a project by copying it to the lib folder.)
The publishLocal action is used to publish your project to a local Ivy repository. By default, this local repository is in ${user.home}/.ivy2/local. You can then use this project from other projects on the same machine source
EDIT: Sorry I misread your question. Here is an example to publish a jar or sources to your local ivy repo.
tl;dr I'd call it a trick not a feature of sbt. You've been warned.
Let's say you've got file.jar to publish. As is for any build tool, sbt including, it's to execute tasks that eventually create an artifact - a jar file in most cases - out of the files in a project.
The project sets the coordinates for the artifact.
The trick is to leverage what sbt requires to set up the environment (= the coordinates) for the jar to be published (otherwise you'd have to specify them on command line that may or may not be very user friendly).
Create a build.sbt with the necessary settings - organization, name, version and possibly scalaVersion - and save it where the jar file is.
organization := "org.abc"
name := "my-own-publish-jar"
version := "1.0.0"
scalaVersion := "2.11.3"
packageBin in Compile := file(s"${name.value}_${scalaBinaryVersion.value}.jar")
You may've noticed, the build changes compile:package task to point at the jar file.
That's it.
Execute sbt publishLocal and the jar file should be in the Ivy2 local repository, i.e. ~/.ivy2/local/org.abc/my-own-publish-jar_2.11/1.0.0/jars/my-own-publish-jar_2.11.jar.
protip Writing a plugin to do it with the coordinates specified on command line should be quite easy now.
Let's say you have wetElephant.jar and wetElephant-javadoc.jar files some 3rd party library and corresponding javadocs which you want to publish to your local repo and referrence it from another project using libraryDependencies sbt taskKey.
Here's what you need to do.
Put your libraries (wetElephant.jar and wetElephant-javadoc.jar) into modules\wetElephant
Define project in your build.sbt file (or Build.scala file)
lazy val stolenLib = project
.in(file("modules/wetElephant"))
.settings(
organization := "com.stolenLibs",
name := "wetElephant",
version := "0.1-IDonKnow",
crossPaths := false, //don't add scala version to this artifacts in repo
publishMavenStyle := true,
autoScalaLibrary := false, //don't attach scala libs as dependencies
description := "project for publishing dependency to maven repo, use 'sbt publishLocal' to install it",
packageBin in Compile := baseDirectory.value / s"${name.value}.jar",
packageDoc in Compile := baseDirectory.value / s"${name.value}-javadoc.jar"
)
Call publishLocal task from sbt/activator (I did it from activator and prefixed it with proejct name):
./activator wetElephant/publishLocal
... and read the output to see what and where was published:
/cygdrive/d/devstation-workspace/projects/m4l-patches 1
[info] Loading project definition from D:\devstation-workspace\projects\m4l-patches\project
[info] Set current project to m4l-patches (in build file:/D:/devstation-workspace/projects/m4l-patches/)
[info] Updating {file:/D:/devstation-workspace/projects/m4l-patches/}wetElephant...
[info] Packaging D:\devstation-workspace\projects\m4l-patches\modules\wetElephant\target\wetelephant-0.1-IDonKnow-sources.jar ...
[info] Done packaging.
[info] Wrote D:\devstation-workspace\projects\m4l-patches\modules\wetElephant\target\wetelephant-0.1-IDonKnow.pom
[info] Resolving org.fusesource.jansi#jansi;1.4 ...4 ....
[info] Done updating.
[info] :: delivering :: com.stolenLibs#wetelephant;0.1-IDonKnow :: 0.1-IDonKnow :: release :: Sun Dec 20 20:09:24 CET 2015
[info] delivering ivy file to D:\devstation-workspace\projects\m4l-patches\modules\wetElephant\target\ivy-0.1-IDonKnow.xml
[info] published wetelephant to C:\Users\pawell\.ivy2\local\com.stolenLibs\wetelephant\0.1-IDonKnow\poms\wetelephant.pom
[info] published wetelephant to C:\Users\pawell\.ivy2\local\com.stolenLibs\wetelephant\0.1-IDonKnow\jars\wetelephant.jar
[info] published wetelephant to C:\Users\pawell\.ivy2\local\com.stolenLibs\wetelephant\0.1-IDonKnow\srcs\wetelephant-sources.jar
[info] published wetelephant to C:\Users\pawell\.ivy2\local\com.stolenLibs\wetelephant\0.1-IDonKnow\docs\wetelephant-javadoc.jar
[info] published ivy to C:\Users\pawell\.ivy2\local\com.stolenLibs\wetelephant\0.1-IDonKnow\ivys\ivy.xml
[success] Total time: 1 s, completed 2015-12-20 20:09:24
Optionally use these libraries in another project
libraryDependencies += "com.stolenLibs" % "wetElephant" % "0.1-IDontKnow"
Disclaimer: I don't know how not to publish sources...
Here is a blog post I followed to push sbt artifact to a maven repository (local and remote) a few months ago.
http://brizzled.clapper.org/id/100/
Try this:
http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html
I created a sample Play Framework/sbt project that creates a local repository (not just publish-local) here: https://github.com/muymoo/local-ivy-repo-sbt
Specifically look at Build.scala
makeLocalRepoSettings(publishedProjects):_*
and
localRepoArtifacts += "org.apache.ws.security" % "wss4j" % "1.6.9"
These localRepoArtifacts are found in my local ivy repo, but I think you could edit this to work with plain old jar files as well.
To run: play local-repository-created
It is a simpler version of https://github.com/sbt/sbt-remote-control which does a whole lot more in their Build.scala.

Why is sbt current project name "default" in 0.10?

I'm using sbt 0.10 to build a Scala project using just a build.sbt file instead of a full configuration.
Every time I start sbt it gives me the messages as follows:
[info] Set current project to default-ee699e (in build file:/Users/.../project/plugins/)
[info] Set current project to default-8febe7 (in build file:/Users/.../)
I did set the name and mainClass settings in the build.sbt file, so I don't know what I need to set to get the project names default-XXXX go away.
EDIT: the answer given below is correct in that this is cosmetic. If you switch to a full configuration of sbt, then it uses that project's name as opposed to default-XXXX however.
The message can be a bit misleading, it's not saying that you must "set the curent project", it's telling you what it's doing.
It sets the current project to the plugins folder, does it's stuff (compile, etc.), then sets the current project to your actual build folder and does it's thing once again.
You don't need to set anything else.

Resources