This page is a relatively complete list of command line options, commands, and tasks you can use from the sbt interactive prompt or in batch mode. See Running in the Getting Started Guide for an intro to the basics, while this page has a lot more detail.
toStringrepresentation of these values can be shown using
show <task>to run the task instead of just
cleanDeletes all generated files (the
publishLocalPublishes artifacts (such as jars) to the local Ivy repository as described in Publishing.
publishPublishes artifacts (such as jars) to the repository defined by the publishTo setting, described in Publishing.
updateResolves and retrieves external dependencies as described in library dependencies.
Configuration-level tasks are tasks associated with a configuration. For
compile, which is equivalent to
the main source code (the
compiles the test source code (test
test configuration). Most tasks
compile configuration have an equivalent in the
configuration that can be run using a
compileCompiles the main sources (in the
Test/compilecompiles test sources (in the src/test/scala/ directory).
consoleStarts the Scala interpreter with a classpath including the compiled sources, all jars in the lib directory, and managed libraries. To return to sbt, type :quit, Ctrl+D (Unix), or Ctrl+Z (Windows). Similarly, Test/console starts the interpreter with the test classes and classpath.
consoleQuickStarts the Scala interpreter with the project’s compile-time dependencies on the classpath. Test/consoleQuick uses the test dependencies. This task differs from console in that it does not force compilation of the current project’s sources.
consoleProjectEnters an interactive session with sbt and the build definition on the classpath. The build definition and related values are bound to variables and common packages and values are imported. See the consoleProject documentation for more information.
docGenerates API documentation for Scala source files in
Test/docgenerates API documentation for source files in
packageCreates a jar file containing the files in
src/main/resourcesand the classes compiled from
Test/packagecreates a jar containing the files in
src/test/resourcesand the class compiled from
packageDocCreates a jar file containing API documentation generated from Scala source files in src/main/scala. Test/packageDoc creates a jar containing API documentation for test sources files in src/test/scala.
packageSrc: Creates a jar file containing all main source files and resources. The packaged paths are relative to src/main/scala and src/main/resources. Similarly, Test/packageSrc operates on test source files and resources.
run <argument>*Runs the main class for the project in the same virtual machine as sbt. The main class is passed the arguments provided. Please see Running Project Code for details on the use of System.exit and multithreading (including GUIs) in code run by this action.
Test/runruns a main class in the test code.
runMain <main-class> <argument>*Runs the specified main class for the project in the same virtual machine as sbt. The main class is passed the arguments provided. Please see Running Project Code for details on the use of System.exit and multithreading (including GUIs) in code run by this action.
Test/runMainruns the specified main class in the test code.
testRuns all tests detected during test compilation. See Testing for details.
testOnly <test>*Runs the tests provided as arguments.
*(will be) interpreted as a wildcard in the test name. See Testing for details.
testQuick <test>* Runs the tests specified as arguments (or all
tests if no arguments are given) that:
*(will be) interpreted as a wildcard in the test name. See [Testing][Testing] for details.
quitEnd the current interactive session or build. Additionally, Ctrl+D (Unix) or Ctrl+Z (Windows) will exit the interactive prompt.
help <command>Displays detailed help for the specified command. If the command does not exist, help lists detailed help for commands whose name or description match the argument, which is interpreted as a regular expression. If no command is provided, displays brief descriptions of the main commands. Related commands are tasks and settings.
projects [add|remove <URI>]List all available projects if no arguments provided or adds/removes the build at the provided URI. (See multi-project builds for details on multi-project builds.)
project <project-id>Change the current project to the project with ID
<project-id>. Further operations will be done in the context of the given project. (See multi-project builds for details on multiple project builds.)
~ <command>Executes the project specified action or method whenever source files change. See Triggered Execution for details.
< filenameExecutes the commands in the given file. Each command should be on its own line. Empty lines and lines beginning with ’#’ are ignored
+ <command>Executes the project specified action or method for all versions of Scala defined in the crossScalaVersions setting.
++ <version|home-directory> <command>Temporarily changes the version of Scala building the project and executes the provided command.
<command>is optional. The specified version of Scala is used until the project is reloaded, settings are modified (such as by the set or session commands), or ++ is run again.
<version>does not need to be listed in the build definition, but it must be available in a repository. Alternatively, specify the path to a Scala installation.
; A ; BExecute A and if it succeeds, run B. Note that the leading semicolon is required.
eval <Scala-expression> Evaluates the given Scala expression and
returns the result and inferred type. This can be used to set system
properties, as a calculator, to fork processes, etc … For example:
> eval System.setProperty("demo", "true") > eval 1+1 > eval "ls -l" !
reload [plugins|return]If no argument is specified, reloads the build, recompiling any build or plugin definitions as necessary. reload plugins changes the current project to the build definition project (in
project/). This can be useful to directly manipulate the build definition. For example, running clean on the build definition project will force snapshots to be updated and the build definition to be recompiled. reload return changes back to the main project.
set <setting-expression>Evaluates and applies the given setting definition. The setting applies until sbt is restarted, the build is reloaded, or the setting is overridden by another set command or removed by the session command. See .sbt build definition and Inspecting Settings for details.
session <command>Manages session settings defined by the
setcommand. It can persist settings configured at the prompt. See Inspecting Settings for details.
inspect <setting-key>Displays information about settings, such as the value, description, defining scope, dependencies, delegation chain, and related settings. See Inspecting Settings for details.
When launching the
sbt runner from the OS shell, various system properties
or JVM extra options can be specified to influence its behaviour.
SBT_OPTS environment variables are defined when
sbt starts, their content is passed as command line arguments to the JVM
If a file named
.jvmopt exists in the current directory, its content
is appended to
JAVA_OPTS at sbt startup. Similarly, if
/etc/sbt/sbtopts exist, their content is appended to
The default value of
You can also specify JVM system properties and command line options
sbt arguments: any
-Dkey=val argument will be passed
as-is to the JVM, and any
-J-Xfoo will be passed as
sbt --help for more details.
If you find yourself running out of permgen space or your workstation is low on memory, adjust the JVM configuration as you would for any java application.
For example a common set of memory-related options is:
export SBT_OPTS="-Xmx2048M -Xss2M" sbt
Or if you prefer to specify them just for this session:
sbt -J-Xmx2048M -J-Xss2M
sbt is just a bootstrap, the actual meat of sbt, the Scala compiler
and standard library are by default downloaded to the shared directory
To change the location of this directory, set the
system property. A relative path will be resolved
against the current working directory, which can be useful if you want
to avoid sharing the boot directory between projects. For example, the
following uses the pre-0.11 style of putting the boot directory in
The character encoding used by your terminal may differ from Java’s
default encoding for your platform. In this case, you will need to specify
file.encoding=<encoding> system property, which might look like:
export JAVA_OPTS="-Dfile.encoding=Cp1252" sbt
On Unix, sbt will pick up any HTTP, HTTPS, or FTP proxy settings from
variables. If you are behind a proxy requiring authentication, you
need to pass some supplementary flags at sbt startup. See
JVM networking system properties for more details.
sbt -Dhttp.proxyUser=username -Dhttp.proxyPassword=mypassword
On Windows, your script should set properties for proxy host, port, and if applicable, username and password. For example, for HTTP:
sbt -Dhttp.proxyHost=myproxy -Dhttp.proxyPort=8080 -Dhttp.proxyUser=username -Dhttp.proxyPassword=mypassword
ftp in the above command line to
configure HTTPS or FTP.
The following system properties can also be passed to
|sbt.banner||Boolean||true (in 1.3+)||Show a welcome banner advertising new features.|
|sbt.boot.directory||Directory||~/.sbt/boot||Path to shared boot directory. You should define sbt.boot.directory explicitly if you are using sbt in a CI environment and want to cache sbt boot classes between runs.|
|sbt.boot.properties||File||Roughly sbt.boot.properties internal to the sbt launcher and specific to the sbt version.||The path to find the sbt boot properties file. This can be a relative path, relative to the sbt base directory, the users home directory or the location of the sbt jar file, or it can be an absolute path or an absolute file URI.|
|sbt.ci||Boolean||false (unless then env var BUILD_NUMBER is set)||For continuous integration environments. Suppress supershell and color.|
|sbt.color||String||auto||Supercedes sbt.log.format. To turn on color, use always or true. To turn off color, use never or false>. To use color if the output is a terminal (not a pipe) that supports color, use auto.|
|sbt.coursier||Boolean||true (in 1.3+)||Use coursier to retrieve packages. (See also sbt.ivy.)|
|sbt.coursier.home||Directory||CoursierDependencyResolution.defaultCacheLocation (in 1.3+)||Location of coursier artifact cache, where the default is defined by Coursier cache resolution logic. You can verify the value with the command `csrCacheDirectory`. You should define sbt.coursier.home explicitly if you are using coursier in a CI environment and want to cache artifacts between runs.|
|sbt.extraClasspath||Classpath Entries||(jar files or directories) that are added to sbt's classpath. Note that the entries are delimited by comma, e.g.: entry1, entry2,... See also resource in the sbt launcher documentation.|
|sbt.genbuildprops||Boolean||true||Generate build.properties if missing. If unset, this defers to sbt.skip.version.write.|
|sbt.global.base||Directory||$HOME/.sbt/1.0||The directory containing global settings and plugins.|
|xsbt.inc.debug||Boolean||false||Extra debugging for the incremental debugger.|
|sbt.ivy||Boolean||true (in <1.3)||Use ivy to retrieve packages.|
|sbt.ivy.home||Directory||~/.ivy2||The directory containing the local Ivy repository and artifact cache. You should define sbt.ivy.home explicitly if you are using sbt in a CI environment and want to cache ivy artifacts between runs.|
|sbt.log.noformat||Boolean||false||If true, disable ANSI color codes. Useful on build servers or terminals that do not support color.|
|sbt.main.class||String||sbt.xMain||The sbt class to use (alternatives include sbt.ConsoleMain and sbt.ScriptMain).|
|sbt.offline||Boolean||false||Avoid retrieving classes from repositories.|
|sbt.override.build.repos||Boolean||false||If true, repositories configured in a build definition are ignored and the repositories configured for the launcher are used instead. See sbt.repository.config and the sbt launcher documentation.|
|sbt.progress||String||?||Use always to show progress ("supershell").|
|sbt.repository.config||File||~/.sbt/repositories||A file containing the repositories to use for the launcher. The format is the same as a [repositories] section for a sbt launcher configuration file. This setting is typically used in conjunction with setting sbt.override.build.repos to true (see sbt.override.build.repos and the sbt launcher documentation).|
|sbt.resident.limit||Number||0||The number of scala compilers to keep around. This experimental feature was intended to improve compilation time. It does not appear to have succeeded and this flag will probably be removed.|
|sbt.skip.version.write||Boolean||false||Generate build.properties if missing. See sbt.genbuildprops.|
|sbt.supershell||Boolean||true if color is enabled||Use supershell (show progress at bottom of shell).|
|sbt.supershell.sleep||Number||100||Time to wait between updating the supershell progress area.|
|sbt.task.timings||Boolean||false||Measure the time elapsed for running tasks.|
|sbt.task.timings.omit.paths||Boolean||false||Omit paths when reporting timings.|
|sbt.task.timings.on.shutdown||Boolean||false||Report timings at JVM shutdown (instead of at task completion).|
|sbt.task.timings.threshold||String||0||Omit items from timing report if they are below this threshold.|
|sbt.traces||Boolean||false||Generate Chrome Trace Event Format log for tasks.|
|sbt.turbo||Boolean||false||Use additional layered class loaders.|
|sbt.version||Version||1.8.3||sbt version to use, usually taken from project/build.properties.|
|sbt.watch.mode||String||auto||If polling, check file system periodically for updates.|