mirror of https://github.com/sbt/sbt.git
doc updates, conversions, howto extension, theme from akka
This commit is contained in:
Mark Harrah
parent
b98e12e9dd
commit
3acc17d259
|
|
@ -1,3 +1,4 @@
|
|||
target/
|
||||
project/boot/
|
||||
.release.sbt
|
||||
__pycache__
|
||||
|
|
|
|||
|
|
@ -59,16 +59,13 @@ This is the 0.13.x series of sbt.
|
|||
|
||||
## Building Documentation
|
||||
|
||||
Documentation is built using jekyll and sphinx and requires some external programs and libraries to be manually installed first:
|
||||
Documentation is built using sphinx and requires some external programs and libraries to be manually installed first:
|
||||
|
||||
```text
|
||||
$ pip install pygments
|
||||
$ pip install sphinx
|
||||
$ pip install sphinxcontrib-issuetracker
|
||||
$ gem install rdiscount
|
||||
$ gem install jekyll
|
||||
```
|
||||
|
||||
To build the full site, run the `make-site` task, which will generate the manual, API, SXR, and other site pages in `target/site/`.
|
||||
|
||||
Individual pieces of the site may be generated using `xsbt/sphinx:mappings`, `xsbt/jekyll:mappings`, `xsbt/doc`, or `xsbt/sxr`. The output directories will be under `target/`, such as `target/sphinx`.
|
||||
To only work on the site and not API or SXR, run `sphinx:mappings`.
|
||||
|
|
@ -1,49 +1,63 @@
|
|||
import sbt._
|
||||
import Keys._
|
||||
import Status.{isSnapshot, publishStatus}
|
||||
import com.jsuereth.sbtsite.{SitePlugin, SiteKeys}
|
||||
import SitePlugin.site
|
||||
import com.typesafe.sbt.{SbtGhPages,SbtGit,SbtSite,site=>sbtsite}
|
||||
import SbtSite.{site, SiteKeys}
|
||||
import SbtGhPages.{ghpages, GhPagesKeys => ghkeys}
|
||||
import SbtGit.{git, GitKeys}
|
||||
import sbtsite.SphinxSupport
|
||||
import SiteKeys.{makeSite,siteMappings}
|
||||
import Sxr.sxr
|
||||
|
||||
object Docs
|
||||
{
|
||||
val cnameFile = SettingKey[File]("cname-file", "Location of the CNAME file for the website.")
|
||||
|
||||
def settings: Seq[Setting[_]] =
|
||||
site.settings ++
|
||||
site.sphinxSupport("manual") ++
|
||||
site.jekyllSupport() ++
|
||||
site.sphinxSupport("docs") ++
|
||||
site.includeScaladoc("api") ++
|
||||
siteIncludeSxr ++
|
||||
sitePrefixVersion
|
||||
siteIncludeSxr("sxr") ++
|
||||
ghPagesSettings
|
||||
|
||||
def siteIncludeSxr = Seq(
|
||||
mappings in sxr <<= sxr.map(dir => Path.allSubpaths(dir).toSeq),
|
||||
site.addMappingsToSiteDir(mappings in sxr, "sxr")
|
||||
def ghPagesSettings = ghpages.settings ++ Seq(
|
||||
git.remoteRepo := "git@github.com:sbt/sbt.github.com.git",
|
||||
ghkeys.synchLocal <<= synchLocalImpl,
|
||||
cnameFile <<= (sourceDirectory in SphinxSupport.Sphinx) / "CNAME",
|
||||
GitKeys.gitBranch in ghkeys.updatedRepository := Some("master")
|
||||
)
|
||||
|
||||
def sitePrefixVersion =
|
||||
siteMappings <<= (siteMappings, version) map { (ms, v) =>
|
||||
ms.map { case (src, path) => (src, v + "/" + path) }
|
||||
}
|
||||
def siteIncludeSxr(prefix: String) = Seq(
|
||||
mappings in sxr <<= sxr.map(dir => Path.allSubpaths(dir).toSeq),
|
||||
site.addMappingsToSiteDir(mappings in sxr, prefix)
|
||||
)
|
||||
|
||||
def siteLinkLatest =
|
||||
makeSite <<= (makeSite, version, streams, isSnapshot) map { (dir, v, s, snap) =>
|
||||
linkSite(dir, v, if(snap) "snapshot" else "stable", s.log)
|
||||
dir
|
||||
}
|
||||
def synchLocalImpl = (ghkeys.privateMappings, ghkeys.updatedRepository, version, isSnapshot, streams, cnameFile) map { (mappings, repo, v, snap, s, cname) =>
|
||||
val versioned = repo / v
|
||||
if(snap)
|
||||
IO.delete(versioned)
|
||||
else if(versioned.exists)
|
||||
error("Site for " + v + " already exists: " + versioned.getAbsolutePath)
|
||||
IO.copy(mappings map { case (file, target) => (file, versioned / target) })
|
||||
IO.copyFile(cname, repo / cname.getName)
|
||||
IO.touch(repo / ".nojekyll")
|
||||
linkSite(repo, v, if(snap) "snapshot" else "release", s.log)
|
||||
s.log.info("Copied site to " + versioned)
|
||||
repo
|
||||
}
|
||||
|
||||
def linkSite(base: File, to: String, from: String, log: Logger) {
|
||||
val current = base / to
|
||||
assert(current.isDirectory, "Versioned site not present at " + current.getAbsolutePath)
|
||||
val symlinkFile = base / from
|
||||
symlinkFile.delete()
|
||||
symlink(to = current, from = symlinkFile, log = log)
|
||||
val symlinkDir = base / from
|
||||
symlinkDir.delete()
|
||||
symlink(path = to, file = symlinkDir, log = log)
|
||||
}
|
||||
|
||||
// TODO: platform independence/use symlink from Java 7
|
||||
def symlink(to: File, from: File, log: Logger): Unit =
|
||||
"ln" :: "-s" :: to.getAbsolutePath :: from.getAbsolutePath :: Nil ! log match {
|
||||
def symlink(path: String, file: File, log: Logger): Unit =
|
||||
"ln" :: "-s" :: path :: file.getAbsolutePath :: Nil ! log match {
|
||||
case 0 => ()
|
||||
case code => error("Could not create symbolic link from " + from + " to " + " to.")
|
||||
case code => error("Could not create symbolic link '" + file.getAbsolutePath + "' with path " + path)
|
||||
}
|
||||
}
|
||||
|
|
@ -22,11 +22,17 @@ object Sxr
|
|||
sxr in taskGlobal <<= sxrTask
|
||||
)
|
||||
def taskGlobal = ThisScope.copy(task = Global)
|
||||
def sxrTask = (sources, target, scalacOptions, classpathOptions, scalaInstance, fullClasspath in sxr, streams) map { (srcs, out, opts, cpOpts, si, cp, s) =>
|
||||
IO.delete(out)
|
||||
IO.createDirectory(out)
|
||||
val comp = new compiler.RawCompiler(si, cpOpts, s.log)
|
||||
comp(srcs, cp.files, out, opts)
|
||||
out.getParentFile / (out.getName + ".sxr")
|
||||
def sxrTask = (sources, cacheDirectory, target, scalacOptions, classpathOptions, scalaInstance, fullClasspath in sxr, streams) map { (srcs, cache, out, opts, cpOpts, si, cp, s) =>
|
||||
val outputDir = out.getParentFile / (out.getName + ".sxr")
|
||||
val f = FileFunction.cached(cache / "sxr", FilesInfo.hash) { in =>
|
||||
s.log.info("Generating sxr output in " + outputDir.getAbsolutePath + "...")
|
||||
IO.delete(out)
|
||||
IO.createDirectory(out)
|
||||
val comp = new compiler.RawCompiler(si, cpOpts, s.log)
|
||||
comp(in.toSeq.sorted, cp.files, out, opts)
|
||||
Set(outputDir)
|
||||
}
|
||||
f(srcs.toSet)
|
||||
outputDir
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
libraryDependencies += "net.databinder" %% "dispatch-http" % "0.8.8"
|
||||
|
||||
addSbtPlugin("com.jsuereth" % "sbt-site-plugin" % "0.5.0")
|
||||
addSbtPlugin("com.typesafe.sbt" % "sbt-site" % "0.6.0")
|
||||
|
||||
resolvers += "jgit-repo" at "http://download.eclipse.org/jgit/maven"
|
||||
|
||||
addSbtPlugin("com.typesafe.sbt" % "sbt-ghpages" % "0.5.0")
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
pygments: true
|
||||
name: Simple Build Tool
|
||||
description: Homepage for the Simple Build Tool
|
||||
url: http://scala-sbt.org
|
||||
markdown: rdiscount
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
|
||||
<script type="text/javascript" src="/jquery.scrollto.min.js"></script>
|
||||
<script type="text/javascript">
|
||||
(function($){ $(function(){
|
||||
$("#top").click(function(){ $("#intro").ScrollTo(); })
|
||||
|
||||
var applyH = function() {
|
||||
$("#intro, .feature").each(function (i, elt) {
|
||||
if ($(elt).height() < $(window).height()) {
|
||||
$(elt).height($(window).height());
|
||||
}
|
||||
});
|
||||
};
|
||||
$(window).bind('resize', function() { applyH(); });
|
||||
applyH();
|
||||
|
||||
$('#features a, .st').click(function(e){
|
||||
var h = $(this).attr('href');
|
||||
if(h && h[0] && h[0] == '#') {
|
||||
e.preventDefault();
|
||||
|
||||
$(h).ScrollTo({
|
||||
callback:function(){ window.location.hash = h;}
|
||||
});
|
||||
}
|
||||
});
|
||||
});})(jQuery);
|
||||
</script>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
|
||||
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||||
|
||||
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en-us">
|
||||
<head>
|
||||
<title>{% if page.title %}{{ page.title }} - {% endif %}{{ site.title }}</title>
|
||||
<link href='http://fonts.googleapis.com/css?family=Copse' rel='stylesheet' type='text/css'>
|
||||
<link href='/resources/site.css' rel='stylesheet' type='text/css'>
|
||||
<link href='/resources/syntax.css' rel='stylesheet' type='text/css'>
|
||||
<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js">
|
||||
</script>
|
||||
</head>
|
||||
<body>
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
|
||||
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||||
|
||||
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en-us">
|
||||
<head>
|
||||
<title>{% if page.title %}{{ page.title }} - {% endif %}{{ site.title }}</title>
|
||||
<link href='http://fonts.googleapis.com/css?family=Copse' rel='stylesheet' type='text/css'>
|
||||
<link href='/resources/howto-site.css' rel='stylesheet' type='text/css'>
|
||||
<link href='/resources/syntax.css' rel='stylesheet' type='text/css'>
|
||||
<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js">
|
||||
</script>
|
||||
</head>
|
||||
<body>
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
<!-- Topbar
|
||||
================================================== -->
|
||||
<div class="cf" id="more" >
|
||||
<div id="top">
|
||||
<div class="container">
|
||||
<a class="brand" href="/">SBT</a>
|
||||
<ul class="nav">
|
||||
<li><a href="/learn.html">Learn</a>
|
||||
<li><a href="/download.html">Download</a>
|
||||
<li><a href="/community.html">Community</a></li>
|
||||
<li><a href="#top">Top</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
|
@ -1,23 +0,0 @@
|
|||
{% include howto_header.txt %}
|
||||
|
||||
{% include topbar.txt %}
|
||||
|
||||
<div class="cf" id="container">
|
||||
<div class="span2 columns container-spacer"><p> </p></div>
|
||||
<div id="intro" class="span10 columns content">
|
||||
<div id="head" class="cf">
|
||||
<h2><span style="color:black;">sbt</span> {{page.title}}</h2>
|
||||
</div>
|
||||
<div id="pagecontent" class="cf">
|
||||
{{ content }}
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="span6 columns"><p> </p></div>
|
||||
</div>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
||||
|
||||
|
|
@ -1,65 +0,0 @@
|
|||
{% include header.txt %}
|
||||
|
||||
{% include topbar.txt %}
|
||||
|
||||
<div class="cf" id="container">
|
||||
<div class="span2 columns container-spacer"><p> </p></div>
|
||||
<div id="intro" class="span10 columns content">
|
||||
<div id="head" class="cf">
|
||||
<div id="name" class="left">
|
||||
<h1>sbt</h1>
|
||||
<h2>{{page.title}}</h2>
|
||||
<p id="what">{{page.tagline}}</p>
|
||||
</div>
|
||||
<div class="left page-description" id="vc">
|
||||
{{page.description | markdownify }}
|
||||
</div>
|
||||
</div>
|
||||
<div id="features" class="cf">
|
||||
<div id="feature-list">
|
||||
<ul class="left">
|
||||
{% for link in page.toplinks %}
|
||||
{% capture x %}{% cycle 'odd', 'even' %}{% endcapture %}
|
||||
{% if x == 'odd' %}
|
||||
{% if link.link %}
|
||||
<li><a href="{{link.link}}">{{link.name}}</a></li>
|
||||
{% else %}
|
||||
<li><a href="#{{link.id}}">{{link.name}}</a></li>
|
||||
{% endif %}
|
||||
{% endif %}
|
||||
{% endfor %}
|
||||
</ul>
|
||||
<ul class="left">
|
||||
{% for link in page.toplinks %}
|
||||
{% capture x %}{% cycle 'odd2', 'even2' %}{% endcapture %}
|
||||
{% if x == 'even2' %}
|
||||
{% if link.link %}
|
||||
<li><a href="{{link.link}}">{{link.name}}</a></li>
|
||||
{% else %}
|
||||
<li><a href="#{{link.id}}">{{link.name}}</a></li>
|
||||
{% endif %}
|
||||
{% endif %}
|
||||
{% endfor %}
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
<div id="pagecontent" class="cf">
|
||||
{{ content }}
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div id="extra">
|
||||
<ul id="examples">
|
||||
{% for link in page.toplinks %}{% if link.content %}
|
||||
{% if link.content %}
|
||||
<li id="{{link.id}}" class="feature contained">{{ link.content | markdownify }}</li>
|
||||
{% endif %}
|
||||
{% endif %}{% endfor %}
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
<div class="span6 columns"><p> </p></div>
|
||||
</div>
|
||||
|
||||
|
||||
{% include footer.txt %}
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
{% include howto_header.txt %}
|
||||
|
||||
<div class="cf" id="container">
|
||||
<div class="span2 columns container-spacer"><p> </p></div>
|
||||
<div id="intro" class="span10 columns content">
|
||||
<div id="head" class="cf">
|
||||
<h2>{{page.title}}</h2>
|
||||
</div>
|
||||
<div class="cf"><div id="feature-list">
|
||||
<h3> How to ...</h3>
|
||||
<ul class="left" id="section-toc">
|
||||
{% for section in page.sections %}
|
||||
<li id="feature"><h5>... <a href="#{{section.id}}">{{section.name}}</a></h5></li>
|
||||
{% endfor %}
|
||||
</ul>
|
||||
</div></div>
|
||||
<div id="pagecontent" class="cf">
|
||||
{{ content }}
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
{% include footer.txt %}
|
||||
|
|
@ -1,66 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Community Plugins
|
||||
tagline: ensuring everything is possible.
|
||||
description: 'The [SBT Organization](http://github.com/sbt) contains a [SBT Community Plugins](http://github.com/sbt/sbt-community-plugins) project. This project aims to unify all the SBT plugins in the community and ensure their compatibility and timely releases with new versions of SBT. There is also a [list of plugins](https://github.com/harrah/xsbt/wiki/sbt-0.10-plugins-list) that is up-to-date.'
|
||||
toplinks:
|
||||
|
||||
- name: 'Available Plugins'
|
||||
link: 'plugins.html'
|
||||
- name: 'Community Ivy repository'
|
||||
id: 'communityrepo'
|
||||
content: |
|
||||
#### Community Ivy Repository ####
|
||||
[Typesafe, Inc.](http://www.typesafe.com) has provided a freely available [Ivy Repository](http://scalasbt.artifactoryonline.com/scalasbt) for SBT projects to make use of.
|
||||
|
||||
If you would like to publish your project to this Ivy repository, first contact [sbt-repo-admins](http://groups.google.com/group/sbt-repo-admins?hl=en) and request privileges
|
||||
(we have to verify code ownership, rights to publish, etc.). After which, you can deploy your plugins using the following configuration:
|
||||
|
||||
publishTo := Some(Resolver.url("sbt-plugin-releases", new URL("http://scalasbt.artifactoryonline.com/scalasbt/sbt-plugin-releases/"))(Resolver.ivyStylePatterns))
|
||||
|
||||
publishMavenStyle := false
|
||||
|
||||
You'll also need to add your credentials somewhere. I use a `~/.sbt/sbtpluginpublish.sbt` file:
|
||||
|
||||
credentials += Credentials("Artifactory Realm", "scalasbt.artifactoryonline.com", "jsuereth", "@my encrypted password@")
|
||||
|
||||
Where `@my encrypted password@` is actually obtained using the following [instructions](http://wiki.jfrog.org/confluence/display/RTF/Centrally+Secure+Passwords).
|
||||
|
||||
*Note: Your code must abide by the [repository polices](repository-rules.html).*
|
||||
|
||||
To automatically deploy snapshot/release versions of your plugin use
|
||||
the following configuration:
|
||||
|
||||
publishTo <<= (version) { version: String =>
|
||||
val scalasbt = "http://scalasbt.artifactoryonline.com/scalasbt/"
|
||||
val (name, url) = if (version.contains("-SNAPSHOT"))
|
||||
("sbt-plugin-snapshots", scalasbt+"sbt-plugin-snapshots")
|
||||
else
|
||||
("sbt-plugin-releases", scalasbt+"sbt-plugin-releases")
|
||||
Some(Resolver.url(name, new URL(url))(Resolver.ivyStylePatterns))
|
||||
}
|
||||
|
||||
*Note: ivy repositories currently don't support Maven-style snapshots.*
|
||||
- name: 'SBT Organization'
|
||||
id: 'sbtorg'
|
||||
content: |
|
||||
#### SBT Organization ####
|
||||
|
||||
The [SBT Organization](http://github.com/sbt) is available for use by any SBT plugin.
|
||||
Developers who contribute their plugins into the community organization will still retain
|
||||
control over their repository and its access. The Goal of the SBT organization is to
|
||||
organize SBT software into one central location.
|
||||
|
||||
A side benefit to using the SBT organization for projects is that you can use gh-pages to host websites in the http://scala-sbt.org domain.
|
||||
|
||||
- name: 'Community Plugin Build'
|
||||
id: 'pluginbuild'
|
||||
content: |
|
||||
#### SBT Community Plugin Build ####
|
||||
|
||||
The [SBT Community Plugins](http://github.com/sbt/sbt-community-plugins) project aims to build *all* SBT plugins in a single build.
|
||||
This should enable thorough testing of plugins and ensure that plugins work together.
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Community
|
||||
tagline: Amazing People, including you
|
||||
description: |
|
||||
A wonderful, highly engaged community that you can talk to and be a part of.
|
||||
toplinks:
|
||||
- name: 'Mailing List'
|
||||
link: 'http://groups.google.com/group/simple-build-tool/topics'
|
||||
- name: 'Community Plugins'
|
||||
link: 'community-plugins.html'
|
||||
- name: 'Source Code'
|
||||
link: 'http://github.com/harrah/xsbt'
|
||||
---
|
||||
|
|
@ -1,85 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: download
|
||||
tagline: up and running in moments.
|
||||
description: |
|
||||
The [SBT Launcher](http://github.com/sbt/sbt-launcher-package) project contains a set of native packages for use in your operating system.
|
||||
|
||||
[msi](#windows) | [yum](#rpm) | [apt-get](#deb) | [homebrew](#mac) | [by hand](#manual)
|
||||
|
||||
toplinks:
|
||||
- name: 'Windows MSI downloads'
|
||||
id: 'windows'
|
||||
content: |
|
||||
#### Windows Releases ####
|
||||
|
||||
[Click here](http://scalasbt.artifactoryonline.com/scalasbt/sbt-native-packages/org/scala-sbt/sbt/0.12.0/sbt.msi) for the latest windows MSI.
|
||||
|
||||
*Note: please make sure to report any issues you may find [here](https://github.com/sbt/sbt-launcher-package/issues).*
|
||||
- name: 'Yum Repository'
|
||||
id: 'rpm'
|
||||
content: |
|
||||
#### Yum Repositories ####
|
||||
|
||||
The sbt package is available from the [Typesafe Yum Repository](http://rpm.typesafe.com).
|
||||
Please install [this rpm](http://rpm.typesafe.com/typesafe-repo-2.0.0-1.noarch.rpm) to add the typesafe yum repository to your list of approved sources.
|
||||
Then run:
|
||||
|
||||
yum install sbt
|
||||
|
||||
to grab the latest release of sbt.
|
||||
|
||||
*Note: please make sure to report any issues you may find [here](https://github.com/sbt/sbt-launcher-package/issues).*"
|
||||
- name: 'Apt Repository'
|
||||
id: 'deb'
|
||||
content: |
|
||||
#### APT Repositories ####
|
||||
|
||||
The sbt package is available from the [Typesafe Debian Repository](http://apt.typesafe.com).
|
||||
Please install [this deb](http://apt.typesafe.com/repo-deb-build-0002.deb) to enable the typesafe repository.
|
||||
Then run:
|
||||
|
||||
apt-get install sbt
|
||||
|
||||
to grab the latest release of sbt.
|
||||
|
||||
*Note: please make sure to report any issues you may find [here](https://github.com/sbt/sbt-launcher-package/issues).*"
|
||||
- name: 'Homebrew'
|
||||
id: 'mac'
|
||||
content: |
|
||||
#### Hombrew ####
|
||||
|
||||
Use HomeBrew:
|
||||
|
||||
$ brew install sbt
|
||||
- name: 'Manual Installation'
|
||||
id: 'manual'
|
||||
content: |
|
||||
#### Pre-Built Zip files ###
|
||||
Download one of the pre-built [zip](http://scalasbt.artifactoryonline.com/scalasbt/sbt-native-packages/org/scala-sbt/sbt/0.12.0/sbt.zip)
|
||||
or [tgz](http://scalasbt.artifactoryonline.com/scalasbt/sbt-native-packages/org/scala-sbt/sbt/0.12.0/sbt.tgz) and
|
||||
add the bin/ to your path.
|
||||
|
||||
#### By Hand installation ####
|
||||
First, download the [launcher jar](http://typesafe.artifactoryonline.com/typesafe/ivy-releases/org.scala-sbt/sbt-launch/0.12.0/sbt-launch.jar)
|
||||
and place it somewhere useful.
|
||||
THEN, create a script in that same directory.
|
||||
##### Windows #####
|
||||
Create a `sbt.bat` file next to the launch jar.
|
||||
|
||||
set SCRIPT_DIR=%~dp0
|
||||
java -Xmx512M -jar "%SCRIPT_DIR%sbt-launch.jar" %*
|
||||
|
||||
Add the directory containing `sbt.bat` to the windows path.
|
||||
##### Unix-Like #####
|
||||
Create a `sbt` script (a good place is `~/bin/sbt`
|
||||
|
||||
java -Xmx512M -jar `dirname $0`/sbt-launch.jar "$@"
|
||||
|
||||
then make the script executable:
|
||||
|
||||
$ chmod u+x ~/bin/sbt
|
||||
---
|
||||
|
||||
<!-- This page has no content. -->
|
||||
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
---
|
||||
layout: content
|
||||
title: How to...
|
||||
description: How to do common tasks.
|
||||
---
|
||||
|
||||
{% capture table %}
|
||||
{% for page in site.pages %}
|
||||
{% if page.sections %}
|
||||
### {{page.title}} [(details)]({{page.url}}) ###
|
||||
{% for section in page.sections %}
|
||||
... {{section.name}} [(details)]({{page.url | append: "#" | append: section.id}})
|
||||
{% if section.short %} {{section.short | strip_newlines | markdownify}}
|
||||
{% elsif section.batch %} {% highlight console %} $ sbt {{section.batch | strip_newlines}} {% endhighlight %}
|
||||
{% elsif section.setting %} {% highlight scala %} {{section.setting | strip_newlines}} {% endhighlight %}
|
||||
{% elsif section.command %} {% highlight console %} > {{section.command | strip_newlines}} {% endhighlight %}
|
||||
{% elsif section.commands %} {% highlight console %} {{section.commands}} {% endhighlight %}
|
||||
{% endif %}
|
||||
|
||||
|
||||
{% endfor %}
|
||||
{% endif %}
|
||||
{% endfor %}
|
||||
{% endcapture %}
|
||||
|
||||
{{ table | unindent | markdownify }}
|
||||
|
|
@ -1,76 +0,0 @@
|
|||
---
|
||||
layout: howto
|
||||
title: Generating files
|
||||
sections:
|
||||
- id: sources
|
||||
name: generate sources
|
||||
setting: 'sourceGenerators in Compile <+= <your Task[Seq[File]] here>'
|
||||
- id: resources
|
||||
name: generate resources
|
||||
setting: 'resourceGenerators in Compile <+= <your Task[Seq[File]] here>'
|
||||
---
|
||||
|
||||
sbt provides standard hooks for adding source or resource generation tasks.
|
||||
|
||||
<h4 id="sources">Generate sources</h4>
|
||||
|
||||
A source generation task should generate sources in a subdirectory of `sourceManaged` and return a sequence of files generated. The key to add the task to is called `sourceGenerators`. It should be scoped according to whether the generated files are main (`Compile`) or test (`Test`) sources. This basic structure looks like:
|
||||
|
||||
{% highlight scala %}
|
||||
sourceGenerators in Compile <+= <your Task[Seq[File]] here>
|
||||
{% endhighlight %}
|
||||
|
||||
For example, assuming a method `def makeSomeSources(base: File): Seq[File]`,
|
||||
|
||||
{% highlight scala %}
|
||||
sourceGenerators in Compile <+= sourceManaged in Compile map { outDir: File =>
|
||||
makeSomeSources(outDir / "demo")
|
||||
}
|
||||
{% endhighlight %}
|
||||
|
||||
As a specific example, the following generates a hello world source file:
|
||||
|
||||
{% highlight scala %}
|
||||
sourceGenerators in Compile <+= sourceManaged in Compile map { dir =>
|
||||
val file = dir / "demo" / "Test.scala"
|
||||
IO.write(file, """object Test extends App { println("Hi") }""")
|
||||
Seq(file)
|
||||
}
|
||||
{% endhighlight %}
|
||||
|
||||
Executing 'run' will print "Hi". Change `Compile` to `Test` to make it a test source. For efficiency, you would only want to generate sources when necessary and not every run.
|
||||
|
||||
By default, generated sources are not included in the packaged source artifact. To do so, add them as you would other mappings. See `Adding files to a package`.
|
||||
|
||||
<h4 id="resources">Generate resources</h4>
|
||||
|
||||
A resource generation task should generate resources in a subdirectory of `resourceManaged` and return a sequence of files generated. The key to add the task to is called `resourceGenerators`. It should be scoped according to whether the generated files are main (`Compile`) or test (`Test`) resources. This basic structure looks like:
|
||||
|
||||
{% highlight scala %}
|
||||
resourceGenerators in Compile <+= <your Task[Seq[File]] here>
|
||||
{% endhighlight %}
|
||||
|
||||
For example, assuming a method `def makeSomeResources(base: File): Seq[File]`,
|
||||
|
||||
{% highlight scala %}
|
||||
resourceGenerators in Compile <+= resourceManaged in Compile map { outDir: File =>
|
||||
makeSomeResources(outDir / "demo")
|
||||
}
|
||||
{% endhighlight %}
|
||||
|
||||
As a specific example, the following generates a properties file containing the application name and version:
|
||||
|
||||
{% highlight scala %}
|
||||
resourceGenerators in Compile <+=
|
||||
(resourceManaged in Compile, name, version) map { (dir, n, v) =>
|
||||
val file = dir / "demo" / "myapp.properties"
|
||||
val contents = "name=%s\nversion=%s".format(n,v)
|
||||
IO.write(file, contents)
|
||||
Seq(file)
|
||||
}
|
||||
}
|
||||
{% endhighlight %}
|
||||
|
||||
Change `Compile` to `Test` to make it a test resource. Normally, you would only want to generate resources when necessary and not every run.
|
||||
|
||||
By default, generated resources are not included in the packaged source artifact. To do so, add them as you would other mappings. See the `Adding files to a package` section.
|
||||
|
|
@ -1,298 +0,0 @@
|
|||
---
|
||||
layout: howto
|
||||
title: Inspect the build
|
||||
sections:
|
||||
- id: taskhelp
|
||||
name: show or search help for a command, task, or setting
|
||||
command: help compile
|
||||
- id: listtasks
|
||||
name: list available tasks
|
||||
command: tasks
|
||||
- id: listsettings
|
||||
name: list available settings
|
||||
command: settings
|
||||
- id: dependencies
|
||||
name: display forward and reverse dependencies of a setting or task
|
||||
command: inspect compile
|
||||
- id: taskdependencytree
|
||||
name: display tree of setting/task dependencies
|
||||
command: inspect compile
|
||||
- id: description
|
||||
name: display the description and type of a setting or task
|
||||
command: help compile
|
||||
- id: delegates
|
||||
name: display the delegation chain of a setting or task
|
||||
command: inspect compile
|
||||
- id: related
|
||||
name: display related settings or tasks
|
||||
command: inspect compile
|
||||
- id: session
|
||||
name: show the current session (temporary) settings
|
||||
command: session list
|
||||
- id: projects
|
||||
name: show the list of projects and builds
|
||||
command: projects
|
||||
- id: about
|
||||
name: show basic information about sbt and the current build
|
||||
command: about
|
||||
- id: value
|
||||
name: show the value of a setting
|
||||
command: show name
|
||||
- id: result
|
||||
name: show the result of executing a task
|
||||
command: show update
|
||||
- id: classpath
|
||||
name: show the classpath used for compilation or testing
|
||||
command: show compile:dependency-classpath
|
||||
- id: applications
|
||||
name: show the main classes detected in a project
|
||||
command: show compile:discovered-main-classes
|
||||
- id: tests
|
||||
name: show the test classes detected in a project
|
||||
command: show defined-test-names
|
||||
---
|
||||
|
||||
[Inspecting Settings]: https://github.com/harrah/xsbt/wiki/Inspecting-Settings
|
||||
|
||||
<h4 id="taskhelp">Show or search help for a command, task, or setting</h4>
|
||||
|
||||
The `help` command is used to show available commands and search the help for commands, tasks, or settings.
|
||||
If run without arguments, `help` lists the available commands.
|
||||
|
||||
{% highlight console %}
|
||||
> help
|
||||
|
||||
help Displays this help message or prints detailed help on
|
||||
requested commands (run 'help <command>').
|
||||
about Displays basic information about sbt and the build.
|
||||
reload (Re)loads the project in the current directory
|
||||
...
|
||||
{% endhighlight %}
|
||||
|
||||
{% highlight console %}
|
||||
> help compile
|
||||
{% endhighlight %}
|
||||
|
||||
If the argument passed to `help` is the name of an existing command, setting or task, the help
|
||||
for that entity is displayed. Otherwise, the argument is interpreted as a regular expression that
|
||||
is used to search the help of all commands, settings and tasks.
|
||||
|
||||
The `tasks` command is like `help`, but operates only on tasks.
|
||||
Similarly, the `settings` command only operates on settings.
|
||||
|
||||
See also `help help`, `help tasks`, and `help settings`.
|
||||
|
||||
<h4 id="listtasks">List available tasks</h4>
|
||||
|
||||
The `tasks` command, without arguments, lists the most commonly used tasks.
|
||||
It can take a regular expression to search task names and descriptions.
|
||||
The verbosity can be increased to show or search less commonly used tasks.
|
||||
See `help tasks` for details.
|
||||
|
||||
<h4 id="listsettings">List available tasks</h4>
|
||||
|
||||
The `settings` command, without arguments, lists the most commonly used settings.
|
||||
It can take a regular expression to search setting names and descriptions.
|
||||
The verbosity can be increased to show or search less commonly used settings.
|
||||
See `help settings` for details.
|
||||
|
||||
<h4 id="dependencies">Display forward and reverse dependencies of a setting or task</h4>
|
||||
|
||||
The `inspect` command displays several pieces of information about a given setting or task, including
|
||||
the dependencies of a task/setting as well as the tasks/settings that depend on the it. For example,
|
||||
|
||||
{% highlight console %}
|
||||
> inspect test:compile
|
||||
...
|
||||
[info] Dependencies:
|
||||
[info] test:compile::compile-inputs
|
||||
[info] test:compile::streams
|
||||
[info] Reverse dependencies:
|
||||
[info] test:defined-test-names
|
||||
[info] test:defined-sbt-plugins
|
||||
[info] test:print-warnings
|
||||
[info] test:discovered-main-classes
|
||||
[info] test:defined-tests
|
||||
[info] test:exported-products
|
||||
[info] test:products
|
||||
...
|
||||
{% endhighlight %}
|
||||
|
||||
See the [Inspecting Settings] page for details.
|
||||
|
||||
<h4 id="taskdependencytree">Display tree of setting/task dependencies</h4>
|
||||
|
||||
In addition to displaying immediate forward and reverse dependencies as described in the previous section,
|
||||
the `inspect` command can display the full dependency tree for a task or setting.
|
||||
For example,
|
||||
|
||||
{% highlight console %}
|
||||
> inspect tree clean
|
||||
[info] *:clean = Task[Unit]
|
||||
[info] +-*:clean-files = List(<project>/lib_managed, <project>/target)
|
||||
[info] | +-{.}/*:managed-directory = lib_managed
|
||||
[info] | +-*:target = target
|
||||
[info] | +-*:base-directory = <project>
|
||||
[info] | +-*:this-project = Project(id: demo, base: <project>, ...
|
||||
[info] |
|
||||
[info] +-*:clean-keep-files = List(<project>/target/.history)
|
||||
[info] +-*:history = Some(<project>/target/.history)
|
||||
...
|
||||
{% endhighlight %}
|
||||
|
||||
For each task, `inspect tree` show the type of the value generated by the task.
|
||||
For a setting, the `toString` of the setting is displayed.
|
||||
See the [Inspecting Settings] page for details on the `inspect` command.
|
||||
|
||||
<h4 id="description">Display the description and type of a setting or task</h4>
|
||||
|
||||
While the `help`, `settings`, and `tasks` commands display a description of a task,
|
||||
the `inspect` command also shows the type of a setting or task and the value of a setting.
|
||||
For example:
|
||||
|
||||
{% highlight console %}
|
||||
> inspect update
|
||||
[info] Task: sbt.UpdateReport
|
||||
[info] Description:
|
||||
[info] Resolves and optionally retrieves dependencies, producing a report.
|
||||
...
|
||||
{% endhighlight %}
|
||||
|
||||
{% highlight console %}
|
||||
> inspect scala-version
|
||||
[info] Setting: java.lang.String = 2.9.2
|
||||
[info] Description:
|
||||
[info] The version of Scala used for building.
|
||||
...
|
||||
{% endhighlight %}
|
||||
|
||||
See the [Inspecting Settings] page for details.
|
||||
|
||||
<h4 id="delegates">Display the delegation chain of a setting or task</h4>
|
||||
|
||||
See the [Inspecting Settings] page for details.
|
||||
|
||||
<h4 id="related">Display related settings or tasks</h4>
|
||||
|
||||
The `inspect` command can help find scopes where a setting or task is defined.
|
||||
The following example shows that different options may be specified to the Scala
|
||||
for testing and API documentation generation.
|
||||
|
||||
{% highlight console %}
|
||||
> inspect scalac-options
|
||||
...
|
||||
[info] Related:
|
||||
[info] compile:doc::scalac-options
|
||||
[info] test:scalac-options
|
||||
[info] */*:scalac-options
|
||||
[info] test:doc::scalac-options
|
||||
{% endhighlight %}
|
||||
|
||||
See the [Inspecting Settings] page for details.
|
||||
|
||||
<h4 id="projects">Show the list of projects and builds</h4>
|
||||
|
||||
The `projects` command displays the currently loaded projects.
|
||||
The projects are grouped by their enclosing build and the current project is indicated by an asterisk.
|
||||
For example,
|
||||
|
||||
{% highlight console %}
|
||||
> projects
|
||||
[info] In file:/home/user/demo/
|
||||
[info] * parent
|
||||
[info] sub
|
||||
[info] In file:/home/user/dep/
|
||||
[info] sample
|
||||
{% endhighlight %}
|
||||
|
||||
<h4 id="session">Show the current session (temporary) settings</h4>
|
||||
|
||||
`session list` displays the settings that have been added at the command line for the current project. For example,
|
||||
|
||||
{% highlight console %}
|
||||
> session list
|
||||
1. maxErrors := 5
|
||||
2. scalacOptions += "-explaintypes"
|
||||
{% endhighlight %}
|
||||
|
||||
`session list-all` displays the settings added for all projects.
|
||||
For details, see `help session`.
|
||||
|
||||
<h4 id="about">Show basic information about sbt and the current build</h4>
|
||||
|
||||
{% highlight console %}
|
||||
> about
|
||||
[info] This is sbt 0.12.0
|
||||
[info] The current project is {file:~/code/sbt.github.com/}default
|
||||
[info] The current project is built against Scala 2.9.2
|
||||
[info] Available Plugins: com.jsuereth.ghpages.GhPages, com.jsuereth.git.GitPlugin, com.jsuereth.sbtsite.SitePlugin
|
||||
[info] sbt, sbt plugins, and build definitions are using Scala 2.9.2
|
||||
{% endhighlight %}
|
||||
|
||||
<h4 id="value">Show the value of a setting</h4>
|
||||
|
||||
The `inspect` shows the value of a setting as part of its output, but the `show` command is dedicated to this job.
|
||||
It shows the output of the setting provided as an argument.
|
||||
For example,
|
||||
|
||||
{% highlight console %}
|
||||
> show organization
|
||||
[info] com.github.sbt
|
||||
{% endhighlight %}
|
||||
|
||||
The `show` command also works for tasks, described next.
|
||||
|
||||
<h4 id="result">Show the result of executing a task</h4>
|
||||
|
||||
{% highlight console %}
|
||||
> show update
|
||||
... <output of update> ...
|
||||
[info] Update report:
|
||||
[info] Resolve time: 122 ms, Download time: 5 ms, Download size: 0 bytes
|
||||
[info] compile:
|
||||
[info] org.scala-lang:scala-library:2.9.2: ...
|
||||
{% endhighlight %}
|
||||
|
||||
The `show` command will execute the task provided as an argument and then print the result.
|
||||
Note that this is different from the behavior of the `inspect` command (described in other sections),
|
||||
which does not execute a task and thus can only display its type and not its generated value.
|
||||
|
||||
<h4 id="compilecp">Show the classpath used for compilation or testing</h4>
|
||||
|
||||
{% highlight console %}
|
||||
> show compile:dependency-classpath
|
||||
...
|
||||
[info] ArrayBuffer(Attributed(~/.sbt/0.12.0/boot/scala-2.9.2/lib/scala-library.jar))
|
||||
{% endhighlight %}
|
||||
|
||||
For the test classpath,
|
||||
|
||||
{% highlight console %}
|
||||
> show test:dependency-classpath
|
||||
...
|
||||
[info] ArrayBuffer(Attributed(~/code/sbt.github.com/target/scala-2.9.2/classes), Attributed(~/.sbt/0.12.0/boot/scala-2.9.2/lib/scala-library.jar), Attributed(~/.ivy2/cache/junit/junit/jars/junit-4.8.2.jar))
|
||||
{% endhighlight %}
|
||||
|
||||
<h4 id="applications">Show the main classes detected in a project</h4>
|
||||
|
||||
sbt detects the classes with public, static main methods for use by the `run` method and to tab-complete the `run-main` method.
|
||||
The `discovered-main-classes` task does this discovery and provides as its result the list of class names.
|
||||
For example, the following shows the main classes discovered in the main sources:
|
||||
|
||||
{% highlight console %}
|
||||
> show compile:discovered-main-classes
|
||||
... <runs compile if out of date> ...
|
||||
[info] List(org.example.Main)
|
||||
{% endhighlight %}
|
||||
|
||||
<h4 id="tests">Show the test classes detected in a project</h4>
|
||||
|
||||
sbt detects tests according to fingerprints provided by test frameworks.
|
||||
The `defined-test-names` task provides as its result the list of test names detected in this way.
|
||||
For example,
|
||||
|
||||
{% highlight console %}
|
||||
> show test:defined-test-names
|
||||
... < runs test:compile if out of date > ...
|
||||
[info] List(org.example.TestA, org.example.TestB)
|
||||
{% endhighlight %}
|
||||
|
|
@ -1,180 +0,0 @@
|
|||
---
|
||||
layout: howto
|
||||
title: Interactive mode
|
||||
sections:
|
||||
- id: basic_completion
|
||||
name: use tab completion
|
||||
command: 'test-only <TAB>'
|
||||
- id: verbose_completion
|
||||
name: show more tab completion suggestions
|
||||
short: Press tab multiple times.
|
||||
- id: show_keybindings
|
||||
name: view basic JLine keybindings
|
||||
commands: |
|
||||
> console-quick
|
||||
scala> :keybindings
|
||||
- id: change_keybindings
|
||||
name: modify the default JLine keybindings
|
||||
- id: prompt
|
||||
name: configure the prompt string
|
||||
setting: 'shellPrompt := { (s: State) => System.getProperty("user.name") + "> " }'
|
||||
- id: history
|
||||
name: use history
|
||||
command: '!'
|
||||
- id: history_file
|
||||
name: change the location of the interactive history file
|
||||
setting: 'historyPath <<= baseDirectory(t => Some(t / ".history"))'
|
||||
- id: share_history
|
||||
name: share interactive history across projects
|
||||
setting: 'historyPath <<= (target in LocalRootProject) { t => Some(t / ".history") }'
|
||||
- id: disable_history
|
||||
name: disable interactive history
|
||||
setting: 'historyPath := None'
|
||||
- id: pre_commands
|
||||
name: start interactive mode after executing some commands first
|
||||
batch: clean compile shell
|
||||
---
|
||||
|
||||
[State]: https://github.com/harrah/xsbt/wiki/Build-State
|
||||
|
||||
By default, sbt's interactive mode is started when no commands are provided on the command line or when the `shell` command is invoked.
|
||||
|
||||
<h4 id="basic_completion">Using tab completion</h4>
|
||||
|
||||
As the name suggests, tab completion is invoked by hitting the tab key.
|
||||
Suggestions are provided that can complete the text entered to the left of the current cursor position.
|
||||
Any part of the suggestion that is unambiguous is automatically appended to the current text.
|
||||
Commands typically support tab completion for most of their syntax.
|
||||
|
||||
As an example, entering `tes` and hitting tab:
|
||||
|
||||
> tes<TAB>
|
||||
|
||||
results in sbt appending a `t`:
|
||||
|
||||
> test
|
||||
|
||||
To get further completions, hit tab again:
|
||||
|
||||
> test<TAB>
|
||||
test-frameworks test-listeners test-loader test-only test-options test:
|
||||
|
||||
Now, there is more than one possibility for the next character, so sbt prints the available options.
|
||||
We will select `test-only` and get more suggestions by entering the rest of the command and hitting tab twice:
|
||||
|
||||
> test-only<TAB><TAB>
|
||||
-- sbt.DagSpecification sbt.EmptyRelationTest sbt.KeyTest sbt.RelationTest sbt.SettingsTest
|
||||
|
||||
The first tab inserts an unambiguous space and the second suggests names of tests to run.
|
||||
The suggestion of `--` is for the separator between test names and options provided to the test framework.
|
||||
The other suggestions are names of test classes for one of sbt's modules.
|
||||
Test name suggestions require tests to be compiled first.
|
||||
If tests have been added, renamed, or removed since the last test compilation, the completions will be out of date until another successful compile.
|
||||
|
||||
<h4 id="verbose_completion">Showing more completions</h4>
|
||||
|
||||
Some commands have different levels of completion. Hitting tab multiple times increases the verbosity of completions. (Presently, this feature is rarely used.)
|
||||
|
||||
<h4 id="show_keybindings">Showing JLine keybindings</h4>
|
||||
|
||||
Both the Scala and sbt command prompts use JLine for interaction. The Scala REPL contains a `:keybindings` command to show many of the keybindings used for JLine. For sbt, this can be used by running one of the `console` commands (`console`, `console-quick`, or `console-project`) and then running `:keybindings`. For example:
|
||||
|
||||
> console-project
|
||||
[info] Starting scala interpreter...
|
||||
...
|
||||
scala> :keybindings
|
||||
Reading jline properties for default key bindings.
|
||||
Accuracy not guaranteed: treat this as a guideline only.
|
||||
|
||||
1 CTRL-A: move to the beginning of the line
|
||||
2 CTRL-B: move to the previous character
|
||||
...
|
||||
|
||||
<h4 id="change_keybindings">Changing JLine keybindings</h4>
|
||||
|
||||
JLine, used by both Scala and sbt, uses a configuration file for many of its keybindings.
|
||||
The location of this file can be changed with the system property `jline.keybindings`.
|
||||
The default keybindings file is included in the sbt launcher and may be used as a starting point for customization.
|
||||
|
||||
<h4 id="prompt">Configure the prompt string</h4>
|
||||
|
||||
By default, sbt only displays `> ` to prompt for a command.
|
||||
This can be changed through the `shellPrompt` setting, which has type `State => String`.
|
||||
[State] contains all state for sbt and thus provides access to all build information for use in the prompt string.
|
||||
|
||||
Examples:
|
||||
{% highlight scala %}
|
||||
// set the prompt (for this build) to include the project id.
|
||||
shellPrompt in ThisBuild := { state => Project.extract(state).currentRef.project + "> " }
|
||||
|
||||
// set the prompt (for the current project) to include the username
|
||||
shellPrompt := { state => System.getProperty("user.name") + "> " }
|
||||
{% endhighlight %}
|
||||
|
||||
<h4 id="history">Using history</h4>
|
||||
|
||||
Interactive mode remembers history even if you exit sbt and restart it.
|
||||
The simplest way to access history is to press the up arrow key to cycle
|
||||
through previously entered commands. Use `Ctrl+r` to incrementally
|
||||
search history backwards. The following commands are supported:
|
||||
|
||||
* `!` Show history command help.
|
||||
* `!!` Execute the previous command again.
|
||||
* `!:` Show all previous commands.
|
||||
* `!:n` Show the last n commands.
|
||||
* `!n` Execute the command with index `n`, as shown by the `!:` command.
|
||||
* `!-n` Execute the nth command before this one.
|
||||
* `!string` Execute the most recent command starting with 'string'
|
||||
* `!?string` Execute the most recent command containing 'string'
|
||||
|
||||
<h4 id="history_file">Changing the history file location</h4>
|
||||
|
||||
By default, interactive history is stored in the `target/` directory for the current project (but is not removed by a `clean`).
|
||||
History is thus separate for each subproject.
|
||||
The location can be changed with the `historyPath` setting, which has type `Option[File]`.
|
||||
For example, history can be stored in the root directory for the project instead of the output directory:
|
||||
|
||||
{% highlight scala %}
|
||||
historyPath <<= baseDirectory(t => Some(t / ".history"))
|
||||
{% endhighlight %}
|
||||
|
||||
The history path needs to be set for each project, since sbt will use the value of `historyPath` for the current project (as selected by the `project` command).
|
||||
|
||||
<h4 id="share_history">Use the same history for all projects</h4>
|
||||
|
||||
The previous section describes how to configure the location of the history file.
|
||||
This setting can be used to share the interactive history among all projects in a build instead of using a different history for each project.
|
||||
The way this is done is to set `historyPath` to be the same file, such as a file in the root project's `target/` directory:
|
||||
|
||||
{% highlight scala %}
|
||||
historyPath <<=
|
||||
(target in LocalRootProject) { t =>
|
||||
Some(t / ".history")
|
||||
}
|
||||
{% endhighlight %}
|
||||
|
||||
The `in LocalRootProject` part means to get the output directory for the root project for the build.
|
||||
|
||||
<h4 id="disable_history">Disable interactive history</h4>
|
||||
|
||||
If, for whatever reason, you want to disable history, set `historyPath` to `None` in each project it should be disabled in:
|
||||
|
||||
{% highlight scala %}
|
||||
historyPath := None
|
||||
{% endhighlight %}
|
||||
|
||||
<h4 id="pre_commands">Run commands before entering interactive mode</h4>
|
||||
|
||||
Interactive mode is implemented by the `shell` command.
|
||||
By default, the `shell` command is run if no commands are provided to sbt on the command line.
|
||||
To run commands before entering interactive mode, specify them on the command line followed by `shell`.
|
||||
For example,
|
||||
|
||||
$ sbt clean compile shell
|
||||
|
||||
This runs `clean` and then `compile` before entering the interactive prompt.
|
||||
If either `clean` or `compile` fails, sbt will exit without going to the prompt.
|
||||
To enter the prompt whether or not these initial commands succeed, prepend `-shell`, which means to run `shell` if any command fails.
|
||||
For example,
|
||||
|
||||
$ sbt -shell clean compile shell
|
||||
|
|
@ -1,254 +0,0 @@
|
|||
---
|
||||
layout: howto
|
||||
title: Configure and use logging
|
||||
sections:
|
||||
- id: last
|
||||
name: view the logging output of the previously executed command
|
||||
command: last
|
||||
- id: tasklast
|
||||
name: view the previous logging output of a specific task
|
||||
command: last compile
|
||||
- id: printwarnings
|
||||
name: show warnings from the previous compilation
|
||||
command: print-warnings
|
||||
- id: level
|
||||
name: change the logging level globally
|
||||
command: set every logLevel := Level.Debug
|
||||
- id: tasklevel
|
||||
name: change the logging level for a specific task, configuration, or project
|
||||
setting: logLevel in compile := Level.Debug
|
||||
- id: trace
|
||||
name: configure printing of stack traces
|
||||
command: set every traceLevel := 5`
|
||||
- id: nobuffer
|
||||
name: print the output of tests immediately instead of buffering
|
||||
setting: logBuffered := false
|
||||
- id: custom
|
||||
name: add a custom logger
|
||||
- id: log
|
||||
name: log messages from a task
|
||||
---
|
||||
|
||||
[print-warnings]: #printwarnings
|
||||
[previous output]: #last
|
||||
[Streams]: http://harrah.github.com/xsbt/latest/api/#sbt.std.Streams
|
||||
|
||||
<h4 id="last">View logging output of the previously executed command</h4>
|
||||
|
||||
When a command is run, more detailed logging output is sent to a file than to the screen (by default).
|
||||
This output can be recalled for the command just executed by running `last`.
|
||||
|
||||
For example, the output of `run` when the sources are uptodate is:
|
||||
|
||||
{% highlight console %}
|
||||
> run
|
||||
[info] Running A
|
||||
Hi!
|
||||
[success] Total time: 0 s, completed Feb 25, 2012 1:00:00 PM
|
||||
{% endhighlight %}
|
||||
|
||||
The details of this execution can be recalled by running `last`:
|
||||
|
||||
{% highlight console %}
|
||||
> last
|
||||
[debug] Running task... Cancelable: false, max worker threads: 4, check cycles: false
|
||||
[debug]
|
||||
[debug] Initial source changes:
|
||||
[debug] removed:Set()
|
||||
[debug] added: Set()
|
||||
[debug] modified: Set()
|
||||
[debug] Removed products: Set()
|
||||
[debug] Modified external sources: Set()
|
||||
[debug] Modified binary dependencies: Set()
|
||||
[debug] Initial directly invalidated sources: Set()
|
||||
[debug]
|
||||
[debug] Sources indirectly invalidated by:
|
||||
[debug] product: Set()
|
||||
[debug] binary dep: Set()
|
||||
[debug] external source: Set()
|
||||
[debug] Initially invalidated: Set()
|
||||
[debug] Copy resource mappings:
|
||||
[debug]
|
||||
[info] Running A
|
||||
[debug] Starting sandboxed run...
|
||||
[debug] Waiting for threads to exit or System.exit to be called.
|
||||
[debug] Classpath:
|
||||
[debug] /tmp/e/target/scala-2.9.2/classes
|
||||
[debug] /tmp/e/.sbt/0.12.0/boot/scala-2.9.2/lib/scala-library.jar
|
||||
[debug] Waiting for thread run-main to exit
|
||||
[debug] Thread run-main exited.
|
||||
[debug] Interrupting remaining threads (should be all daemons).
|
||||
[debug] Sandboxed run complete..
|
||||
[debug] Exited with code 0
|
||||
[success] Total time: 0 s, completed Jan 1, 2012 1:00:00 PM
|
||||
{% endhighlight %}
|
||||
|
||||
Configuration of the logging level for the console and for the backing file are described in following sections.
|
||||
|
||||
<h4 id="tasklast">View the logging output of a specific task</h4>
|
||||
|
||||
When a task is run, more detailed logging output is sent to a file than to the screen (by default).
|
||||
This output can be recalled for a specific task by running `last <task>`.
|
||||
For example, the first time `compile` is run, output might look like:
|
||||
|
||||
{% highlight console %}
|
||||
> compile
|
||||
[info] Updating {file:/.../demo/}example...
|
||||
[info] Resolving org.scala-lang#scala-library;2.9.2 ...
|
||||
[info] Done updating.
|
||||
[info] Compiling 1 Scala source to .../demo/target/scala-2.9.2/classes...
|
||||
[success] Total time: 0 s, completed Jun 1, 2012 1:11:11 PM
|
||||
{% endhighlight %}
|
||||
|
||||
The output indicates that both dependency resolution and compilation were performed.
|
||||
The detailed output of each of these may be recalled individually.
|
||||
For example,
|
||||
|
||||
{% highlight console %}
|
||||
> last compile
|
||||
[debug]
|
||||
[debug] Initial source changes:
|
||||
[debug] removed:Set()
|
||||
[debug] added: Set(/home/mark/tmp/a/b/A.scala)
|
||||
[debug] modified: Set()
|
||||
...
|
||||
{% endhighlight %}
|
||||
|
||||
and:
|
||||
|
||||
{% highlight console %}
|
||||
> last update
|
||||
[info] Updating {file:/.../demo/}example...
|
||||
[debug] post 1.3 ivy file: using exact as default matcher
|
||||
[debug] :: resolving dependencies :: example#example_2.9.2;0.1-SNAPSHOT
|
||||
[debug] confs: [compile, runtime, test, provided, optional, compile-internal, runtime-internal, test-internal, plugin, sources, docs, pom]
|
||||
[debug] validate = true
|
||||
[debug] refresh = false
|
||||
[debug] resolving dependencies for configuration 'compile'
|
||||
...
|
||||
{% endhighlight %}
|
||||
|
||||
|
||||
<h4 id="printwarnings">Display warnings from the previous compilation</h4>
|
||||
|
||||
The Scala compiler does not print the full details of warnings by default.
|
||||
Compiling code that uses the deprecated `error` method from Predef might generate the following output:
|
||||
|
||||
{% highlight console %}
|
||||
> compile
|
||||
[info] Compiling 1 Scala source to <...>/classes...
|
||||
[warn] there were 1 deprecation warnings; re-run with -deprecation for details
|
||||
[warn] one warning found
|
||||
{% endhighlight %}
|
||||
|
||||
The details aren't provided, so it is necessary to add `-deprecation` to the options passed to the compiler (`scalacOptions`) and recompile.
|
||||
An alternative when using Scala 2.10 and later is to run `print-warnings`.
|
||||
This task will display all warnings from the previous compilation.
|
||||
For example,
|
||||
|
||||
{% highlight console %}
|
||||
> print-warnings
|
||||
[warn] A.scala:2: method error in object Predef is deprecated: Use sys.error(message) instead
|
||||
[warn] def x = error("Failed.")
|
||||
[warn] ^
|
||||
{% endhighlight %}
|
||||
|
||||
<h4 id="level">Change the logging level globally</h4>
|
||||
|
||||
The amount of logging is controlled by the `logLevel` setting, which takes values from the `Level` enumeration.
|
||||
Valid values are `Error`, `Warn`, `Info`, and `Debug` in order of increasing verbosity.
|
||||
To change the global logging level, set `logLevel in Global`.
|
||||
For example, to set it temporarily from the sbt prompt,
|
||||
|
||||
{% highlight console %}
|
||||
> set logLevel in Global := Level.Warn
|
||||
{% endhighlight %}
|
||||
|
||||
<h4 id="tasklevel">Change the logging level for a specific task, configuration, or project</h4>
|
||||
|
||||
The amount of logging is controlled by the `logLevel` setting, which takes values from the `Level` enumeration.
|
||||
Valid values are `Error`, `Warn`, `Info`, and `Debug` in order of increasing verbosity.
|
||||
The logging level may be configured globally, as described in the previous section, or it may be applied to a specific project, configuration, or task.
|
||||
For example, to change the logging level for compilation to only show warnings and errors:
|
||||
|
||||
{% highlight console %}
|
||||
> set logLevel in compile := Level.Warn
|
||||
{% endhighlight %}
|
||||
|
||||
To enable debug logging for all tasks in the current project,
|
||||
|
||||
{% highlight console %}
|
||||
> set logLevel := Level.Warn
|
||||
{% endhighlight %}
|
||||
|
||||
A common scenario is that after running a task, you notice that you need more information than was shown by default.
|
||||
A `logLevel` based solution typically requires changing the logging level and running a task again.
|
||||
However, there are two cases where this is unnecessary.
|
||||
First, warnings from a previous compilation may be displayed using `print-warnings` for the main sources or `test:print-warnings` for test sources.
|
||||
Second, output from the previous execution is available either for a single task or for in its entirety.
|
||||
See the section on [print-warnings] and the sections on [previous output].
|
||||
|
||||
<h4 id="trace">Configure printing of stack traces</h4>
|
||||
|
||||
By default, sbt hides the stack trace of most exceptions thrown during execution.
|
||||
It prints a message that indicates how to display the exception.
|
||||
However, you may want to show more of stack traces by default.
|
||||
|
||||
The setting to configure is `traceLevel`, which is a setting with an Int value.
|
||||
When `traceLevel` is set to a negative value, no stack traces are shown.
|
||||
When it is zero, the stack trace is displayed up to the first sbt stack frame.
|
||||
When positive, the stack trace is shown up to that many stack frames.
|
||||
|
||||
For example, the following configures sbt to show stack traces up to the first sbt frame:
|
||||
|
||||
{% highlight console %}
|
||||
> set every traceLevel := 0
|
||||
{% endhighlight %}
|
||||
|
||||
The `every` part means to override the setting in all scopes.
|
||||
To change the trace printing behavior for a single project, configuration, or task, scope `traceLevel` appropriately:
|
||||
|
||||
{% highlight console %}
|
||||
> set traceLevel in Test := 5
|
||||
> set traceLevel in update := 0
|
||||
> set traceLevel in ThisProject := -1
|
||||
{% endhighlight %}
|
||||
|
||||
<h4 id="nobuffer">Print the output of tests immediately instead of buffering</h4>
|
||||
|
||||
By default, sbt buffers the logging output of a test until the whole class finishes.
|
||||
This is so that output does not get mixed up when executing in parallel.
|
||||
To disable buffering, set the `logBuffered` setting to false:
|
||||
|
||||
{% highlight scala %}
|
||||
logBuffered := false
|
||||
{% endhighlight %}
|
||||
|
||||
<h4 id="custom">Add a custom logger</h4>
|
||||
|
||||
The setting `extraLoggers` can be used to add custom loggers.
|
||||
A custom logger should implement [AbstractLogger].
|
||||
`extraLoggers` is a function `ScopedKey[_] => Seq[AbstractLogger]`.
|
||||
This means that it can provide different logging based on the task that requests the logger.
|
||||
|
||||
{% highlight scala %}
|
||||
extraLoggers ~= { currentFunction =>
|
||||
(key: ScopedKey[_]) => {
|
||||
myCustomLogger(key) +: currentFunction(key)
|
||||
}
|
||||
}
|
||||
{% endhighlight %}
|
||||
|
||||
Here, we take the current function for the setting `currentFunction` and provide a new function.
|
||||
The new function prepends our custom logger to the ones provided by the old function.
|
||||
|
||||
<h4 id="log">Log messages in a task</h4>
|
||||
|
||||
The special task `streams` provides per-task logging and I/O via a [Streams] instance.
|
||||
To log, a task maps the `streams` task and uses its `log` member:
|
||||
|
||||
{% highlight scala %}
|
||||
myTask <<= (..., streams) map { (..., s) =>
|
||||
s.log.warn("A warning.")
|
||||
}
|
||||
{% endhighlight %}
|
||||
|
|
@ -1,60 +0,0 @@
|
|||
---
|
||||
layout: howto
|
||||
title: Project metadata
|
||||
sections:
|
||||
- id: name
|
||||
name: set the project name
|
||||
setting: name := "demo"
|
||||
- id: version
|
||||
name: set the project version
|
||||
setting: version := "1.0"
|
||||
- id: organization
|
||||
name: set the project organization
|
||||
setting: organization := "org.example"
|
||||
- id: other
|
||||
name: set the project homepage and other metadata used in a published pom.xml
|
||||
---
|
||||
|
||||
A project should define `name` and `version`. These will be used in various parts of the build, such as the names of generated artifacts. Projects that are published to a repository should also override `organization`.
|
||||
|
||||
<h4 id="name">Set the project name</h4>
|
||||
|
||||
{% highlight scala %}
|
||||
name := "Your project name"
|
||||
{% endhighlight %}
|
||||
|
||||
For published projects, this name is normalized to be suitable for use as an artifact name and dependency ID. This normalized name is stored in `normalizedName`.
|
||||
|
||||
<h4 id="version">Set the project version</h4>
|
||||
|
||||
{% highlight scala %}
|
||||
version := "1.0"
|
||||
{% endhighlight %}
|
||||
|
||||
<h4 id="organization">Set the project organization</h4>
|
||||
|
||||
{% highlight scala %}
|
||||
organization := "org.example"
|
||||
{% endhighlight %}
|
||||
|
||||
By convention, this is a reverse domain name that you own, typically one specific to your project. It is used as a namespace for projects.
|
||||
|
||||
A full/formal name can be defined in the `organizationName` setting. This is used in the generated pom.xml. If the organization has a web site, it may be set in the `organizationHomepage` setting. For example:
|
||||
|
||||
{% highlight scala %}
|
||||
organization := "Example, Inc."
|
||||
|
||||
organizationHomepage := "org.example"
|
||||
{% endhighlight %}
|
||||
|
||||
<h4 id="other">Set the project's homepage and other metadata</h4>
|
||||
|
||||
{% highlight scala %}
|
||||
homepage := Some(url("http://scala-sbt.org"))
|
||||
|
||||
startYear := Some(2008)
|
||||
|
||||
description := "A build tool for Scala."
|
||||
|
||||
licenses += "GPLv2" -> "http://www.gnu.org/licenses/gpl-2.0.html"
|
||||
{% endhighlight %}
|
||||
|
|
@ -1,78 +0,0 @@
|
|||
---
|
||||
layout: howto
|
||||
title: Configure packaging
|
||||
sections:
|
||||
- id: export
|
||||
name: use the packaged jar on classpaths instead of class directory
|
||||
setting: exportJars := true
|
||||
- id: manifest
|
||||
name: add manifest attributes
|
||||
setting: 'packageOptions in (Compile, packageBin) += Package.ManifestAttributes( Attributes.Name.SEALED -> "true" )'
|
||||
- id: name
|
||||
name: change the file name of a package
|
||||
- id: contents
|
||||
name: modify the contents of the package
|
||||
setting: 'mappings in (Compile, packageBin) <+= baseDirectory { dir => ( dir / "example.txt") -> "out/example.txt" }'
|
||||
---
|
||||
|
||||
[mapping files]: https://github.com/harrah/xsbt/wiki/Mapping-Files
|
||||
[Artifacts]: https://github.com/harrah/xsbt/wiki/Artifacts
|
||||
|
||||
<h4 id="export">Use the packaged jar on classpaths instead of class directory</h4>
|
||||
|
||||
By default, a project exports a directory containing its resources and compiled class files. Set `exportJars` to true to export the packaged jar instead. For example,
|
||||
|
||||
{% highlight scala %}
|
||||
exportJars := true
|
||||
{% endhighlight %}
|
||||
|
||||
The jar will be used by `run`, `test`, `console`, and other tasks that use the full classpath.
|
||||
|
||||
<h4 id="manifest">Add attributes to the manifest</h4>
|
||||
|
||||
By default, sbt constructs a manifest for the binary package from settings such as `organization` and `mainClass`. Additional attributes may be added to the `packageOptions` setting scoped by the configuration and package task.
|
||||
|
||||
Main attributes may be added with `Package.ManifestAttributes`. There are two variants of this method, once that accepts repeated arguments that map an attribute of type `java.util.jar.Attributes.Name` to a String value and other that maps attribute names (type String) to the String value.
|
||||
|
||||
For example,
|
||||
|
||||
{% highlight scala %}
|
||||
packageOptions in (Compile, packageBin) +=
|
||||
Package.ManifestAttributes( java.util.jar.Attributes.Name.SEALED -> "true" )
|
||||
{% endhighlight %}
|
||||
|
||||
Other attributes may be added with `Package.JarManifest`.
|
||||
|
||||
{% highlight scala %}
|
||||
packageOptions in (Compile, packageBin) += {
|
||||
import java.util.jar.{Attributes, Manifest}
|
||||
val manifest = new Manifest
|
||||
manifest.getAttributes("foo/bar/").put(Attributes.Name.SEALED, "false")
|
||||
Package.JarManifest( manifest )
|
||||
}
|
||||
{% endhighlight %}
|
||||
|
||||
Or, to read the manifest from a file:
|
||||
|
||||
{% highlight scala %}
|
||||
packageOptions in (Compile, packageBin) += {
|
||||
val manifest = Using.fileInputStream( in => new java.util.jar.Manifest(in) )
|
||||
Package.JarManifest( manifest )
|
||||
}
|
||||
{% endhighlight %}
|
||||
|
||||
<h4 id="name">Change the file name of a package</h4>
|
||||
|
||||
The `artifactName` setting controls the name of generated packages. See the [Artifacts] page for details.
|
||||
|
||||
<h4 id="contents">Modify the contents of the package</h4>
|
||||
|
||||
The contents of a package are defined by the `mappings` task, of type `Seq[(File,String)]`. The `mappings` task is a sequence of mappings from a file to include in the package to the path in the package. See the page on [mapping files] for convenience functions for generating these mappings. For example, to add the file `in/example.txt` to the main binary jar with the path "out/example.txt",
|
||||
|
||||
{% highlight scala %}
|
||||
mappings in (Compile, packageBin) <+= baseDirectory { base =>
|
||||
(base / "in" / "example.txt") -> "out/example.txt"
|
||||
}
|
||||
{% endhighlight %}
|
||||
|
||||
Note that `mappings` is scoped by the configuration and the specific package task. For example, the mappings for the test source package are defined by the `mappings in (Test, packageSrc)` task.
|
||||
|
|
@ -1,70 +0,0 @@
|
|||
---
|
||||
layout: howto
|
||||
title: Running commands
|
||||
sections:
|
||||
- id: batch
|
||||
name: pass arguments to a command or task in batch mode
|
||||
batch: 'clean "test-only org.example.Test" "run-main demo.Main a b c"'
|
||||
- id: multi
|
||||
name: provide multiple commands to run consecutively
|
||||
command: ';clean ;compile'
|
||||
- id: read
|
||||
name: read commands from a file
|
||||
command: '< /path/to/file'
|
||||
- id: alias
|
||||
name: define an alias for a command or task
|
||||
command: 'alias h=help'
|
||||
- id: eval
|
||||
name: quickly evaluate a Scala expression
|
||||
command: 'eval 2+2'
|
||||
---
|
||||
|
||||
<h4 id="batch">Pass arguments to a command in batch mode</h4>
|
||||
|
||||
sbt interprets each command line argument provided to it as a command together with the command's arguments.
|
||||
Therefore, to run a command that takes arguments in batch mode, quote the command and its arguments.
|
||||
For example,
|
||||
|
||||
$ sbt 'project X' clean '~ compile'
|
||||
|
||||
<h4 id="multi">Provide several commands to run consecutively </h4>
|
||||
|
||||
Multiple commands can be scheduled at once by prefixing each command with a semicolon.
|
||||
This is useful for specifying multiple commands where a single command string is accepted.
|
||||
For example, the syntax for triggered execution is `~ <command>`.
|
||||
To have more than one command run for each triggering, use semicolons.
|
||||
For example, the following runs `clean` and then `compile` each time a source file changes:
|
||||
|
||||
> ~ ;clean;compile
|
||||
|
||||
<h4 id="read">Read commands from a file</h4>
|
||||
|
||||
The `<` command reads commands from the files provided to it as arguments. Run `help <` at the sbt prompt for details.
|
||||
|
||||
<h4 id="alias">Set, unset, and show aliases for commands</h4>
|
||||
|
||||
The `alias` command defines, removes, and displays aliases for commands. Run `help alias` at the sbt prompt for details.
|
||||
|
||||
Example usage:
|
||||
|
||||
> alias a=about
|
||||
> alias
|
||||
a = about
|
||||
> a
|
||||
[info] This is sbt ...
|
||||
> alias a=
|
||||
> alias
|
||||
> a
|
||||
[error] Not a valid command: a ...
|
||||
|
||||
<h4 id="eval">Quickly evaluate a Scala expression</h4>
|
||||
|
||||
The `eval` command compiles and runs the Scala expression passed to it as an argument.
|
||||
The result is printed along with its type.
|
||||
For example,
|
||||
|
||||
> eval 2+2
|
||||
4: Int
|
||||
|
||||
Variables defined by an `eval` are not visible to subsequent `eval`s, although changes to system properties persist and affect the JVM that is running sbt.
|
||||
Use the Scala REPL (`console` and related commands) for full support for evaluating Scala code interactively.
|
||||
|
|
@ -1,136 +0,0 @@
|
|||
---
|
||||
layout: howto
|
||||
title: Configure and use Scala
|
||||
sections:
|
||||
- id: version
|
||||
name: set the Scala version used for building the project
|
||||
setting: version := "1.0"
|
||||
- id: noauto
|
||||
name: disable the automatic dependency on the Scala library
|
||||
setting: autoScalaLibrary := false
|
||||
- id: temporary
|
||||
name: temporarily switch to a different Scala version
|
||||
command: ++ 2.8.2
|
||||
- id: local
|
||||
name: use a local Scala installation for building a project
|
||||
setting: scalaHome := Some(file("/path/to/scala/home/"))
|
||||
- id: cross
|
||||
name: build a project against multiple Scala versions
|
||||
- id: console-quick
|
||||
name: enter the Scala REPL with a project's dependencies on the classpath, but not the compiled project classes
|
||||
command: console-quick
|
||||
- id: console
|
||||
name: enter the Scala REPL with a project's dependencies and compiled code on the classpath
|
||||
command: console
|
||||
- id: console-project
|
||||
name: enter the Scala REPL with plugins and the build definition on the classpath
|
||||
command: console-project
|
||||
- id: initial
|
||||
name: define the initial commands evaluated when entering the Scala REPL
|
||||
setting: initialCommands in console := """println("Hi!")"""
|
||||
- id: embed
|
||||
name: use the Scala REPL from project code
|
||||
---
|
||||
|
||||
[console-project]: https://github.com/harrah/xsbt/wiki/Console-Project
|
||||
[cross building]: https://github.com/harrah/xsbt/wiki/Cross-Build
|
||||
[original proposal]: https://gist.github.com/404272
|
||||
|
||||
By default, sbt's interactive mode is started when no commands are provided on the command line or when the `shell` command is invoked.
|
||||
|
||||
<h4 id="version">Set the Scala version used for building the project</h4>
|
||||
|
||||
The `scalaVersion` configures the version of Scala used for compilation. By default, sbt also adds a dependency on the Scala library with this version. See the next section for how to disable this automatic dependency. If the Scala version is not specified, the version sbt was built against is used. It is recommended to explicitly specify the version of Scala.
|
||||
|
||||
For example, to set the Scala version to "2.9.2",
|
||||
|
||||
{% highlight scala %}
|
||||
scalaVersion := "2.9.2"
|
||||
{% endhighlight %}
|
||||
|
||||
<h4 id="noauto">Disable the automatic dependency on the Scala library</h4>
|
||||
|
||||
sbt adds a dependency on the Scala standard library by default. To disable this behavior, set the `autoScalaLibrary` setting to false.
|
||||
|
||||
{% highlight scala %}
|
||||
autoScalaLibrary := false
|
||||
{% endhighlight %}
|
||||
|
||||
<h4 id="temporary">Temporarily switch to a different Scala version</h4>
|
||||
|
||||
To set the Scala version in all scopes to a specific value, use the `++` command. For example, to temporarily use Scala 2.8.2, run:
|
||||
|
||||
> ++ 2.8.2
|
||||
|
||||
<h4 id="local">Use a local Scala version</h4>
|
||||
|
||||
Defining the `scalaHome` setting with the path to the Scala home directory will use that Scala installation. sbt still requires `scalaVersion` to be set when a local Scala version is used. For example,
|
||||
|
||||
{% highlight scala %}
|
||||
scalaVersion := "2.10.0-local"
|
||||
|
||||
scalaHome := Some(file("/path/to/scala/home/"))
|
||||
{% endhighlight %}
|
||||
|
||||
<h4 id="cross">Build a project against multiple Scala versions</h4>
|
||||
|
||||
See [cross building].
|
||||
|
||||
<h4 id="console-quick">Enter the Scala REPL with a project's dependencies on the classpath, but not the compiled project classes</h4>
|
||||
|
||||
The `console-quick` action retrieves dependencies and puts them on the classpath of the Scala REPL. The project's sources are not compiled, but sources of any source dependencies are compiled. To enter the REPL with test dependencies on the classpath but without compiling test sources, run `test:console-quick`. This will force compilation of main sources.
|
||||
|
||||
<h4 id="console">Enter the Scala REPL with a project's dependencies and compiled classes on the classpath</h4>
|
||||
|
||||
The `console` action retrieves dependencies and compiles sources and puts them on the classpath of the Scala REPL. To enter the REPL with test dependencies and compiled test sources on the classpath, run `test:console`.
|
||||
|
||||
<h4 id="console-project">Enter the Scala REPL with plugins and the build definition on the classpath</h4>
|
||||
|
||||
> console-project
|
||||
|
||||
For details, see the [console-project] page.
|
||||
|
||||
<h4 id="initial">Define the initial commands evaluated when entering the Scala REPL</h4>
|
||||
|
||||
Set `initialCommands in console` to set the initial statements to evaluate when `console` and `console-quick` are run. To configure `console-quick` separately, use `initialCommands in consoleQuick`.
|
||||
For example,
|
||||
|
||||
{% highlight scala %}
|
||||
initialCommands in console := """println("Hello from console")"""
|
||||
|
||||
initialCommands in consoleQuick := """println("Hello from console-quick")"""
|
||||
{% endhighlight %}
|
||||
|
||||
The `console-project` command is configured separately by `initialCommands in consoleProject`. It does not use the value from `initialCommands in console` by default. For example,
|
||||
|
||||
{% highlight scala %}
|
||||
initialCommands in consoleProject := """println("Hello from console-project")"""
|
||||
{% endhighlight %}
|
||||
|
||||
<h4 id="embed">Use the Scala REPL from project code</h4>
|
||||
|
||||
sbt runs tests in the same JVM as sbt itself and Scala classes are not in the same class loader as the application classes. This is also the case in `console` and when `run` is not forked. Therefore, when using the Scala interpreter, it is important to set it up properly to avoid an error message like:
|
||||
|
||||
Failed to initialize compiler: class scala.runtime.VolatileBooleanRef not found.
|
||||
** Note that as of 2.8 scala does not assume use of the java classpath.
|
||||
** For the old behavior pass -usejavacp to scala, or if using a Settings
|
||||
** object programmatically, settings.usejavacp.value = true.
|
||||
|
||||
The key is to initialize the Settings for the interpreter using _embeddedDefaults_. For example:
|
||||
|
||||
{% highlight scala %}
|
||||
val settings = new Settings
|
||||
settings.embeddedDefaults[MyType]
|
||||
val interpreter = new Interpreter(settings, ...)
|
||||
{% endhighlight %}
|
||||
|
||||
Here, MyType is a representative class that should be included on the interpreter's classpath and in its application class loader. For more background, see the [original proposal] that resulted in _embeddedDefaults_ being added.
|
||||
|
||||
Similarly, use a representative class as the type argument when using the _break_ and _breakIf_ methods of _ILoop_, as in the following example:
|
||||
|
||||
{% highlight scala %}
|
||||
def x(a: Int, b: Int) = {
|
||||
import scala.tools.nsc.interpreter.ILoop
|
||||
ILoop.breakIf[MyType](a != b, "a" -> a, "b" -> b )
|
||||
}
|
||||
{% endhighlight %}
|
||||
|
|
@ -1,64 +0,0 @@
|
|||
---
|
||||
layout: howto
|
||||
title: Triggered execution
|
||||
sections:
|
||||
- id: basic
|
||||
name: run a command when sources change
|
||||
command: '~ test'
|
||||
- id: multi
|
||||
name: run multiple commands when sources change
|
||||
command: '~ ;a ;b'
|
||||
- id: sources
|
||||
name: configure the sources that are checked for changes
|
||||
setting: 'watchSources <+= baseDirectory { _ / "examples.txt" }'
|
||||
- id: interval
|
||||
name: set the time interval between checks for changes to sources
|
||||
setting: 'pollInterval := 1000 // in ms'
|
||||
---
|
||||
|
||||
<h4 id="basic">Run a command when sources change</h4>
|
||||
|
||||
You can make a command run when certain files change by prefixing the command with `~`. Monitoring is terminated when `enter` is pressed. This triggered execution is configured by the `watch` setting, but typically the basic settings `watch-sources` and `poll-interval` are modified as described in later sections.
|
||||
|
||||
The original use-case for triggered execution was continuous compilation:
|
||||
|
||||
{% highlight scala %}
|
||||
> ~ test:compile
|
||||
|
||||
> ~ compile
|
||||
{% endhighlight %}
|
||||
|
||||
You can use the triggered execution feature to run any command or task, however. The following will poll for changes to your source code (main or test) and run `test-only` for the specified test.
|
||||
|
||||
{% highlight scala %}
|
||||
> ~ test-only example.TestA
|
||||
{% endhighlight %}
|
||||
|
||||
<h4 id="multi">Run multiple commands when sources change</h4>
|
||||
|
||||
The command passed to `~` may be any command string, so multiple commands may be run by separating them with a semicolon. For example,
|
||||
|
||||
{% highlight scala %}
|
||||
> ~ ;a ;b
|
||||
{% endhighlight %}
|
||||
|
||||
This runs `a` and then `b` when sources change.
|
||||
|
||||
<h4 id="sources">Configure the sources checked for changes</h4>
|
||||
|
||||
* `watchSources` defines the files for a single project that are monitored for changes. By default, a project watches resources and Scala and Java sources.
|
||||
* `watchTransitiveSources` then combines the `watchSources` for the current project and all execution and classpath dependencies (see [Full Configuration] for details on inter-project dependencies).
|
||||
|
||||
To add the file `demo/example.txt` to the files to watch,
|
||||
|
||||
{% highlight scala %}
|
||||
watchSources <+= baseDirectory { _ / "demo" / "examples.txt" }
|
||||
{% endhighlight %}
|
||||
|
||||
<h4 id="interval">Configure the polling time</h4>
|
||||
|
||||
`pollInterval` selects the interval between polling for changes in milliseconds. The default value is `500 ms`. To change it to `1 s`,
|
||||
|
||||
{% highlight scala %}
|
||||
pollInterval := 1000 // in ms
|
||||
{% endhighlight %}
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
/*
|
||||
GNU Affero General Public License version 3 {@link http://www.gnu.org/licenses/agpl-3.0.html}
|
||||
*/
|
||||
(function(b){if(b.ScrollTo)window.console.warn("$.ScrollTo has already been defined...");else{b.ScrollTo={config:{duration:400,easing:"swing",callback:undefined,durationMode:"each"},configure:function(c){b.extend(b.ScrollTo.config,c||{});return this},scroll:function(c,d){var f=b.ScrollTo,a=c.pop(),e=a.$container,g=a.$target;a=b("<span/>").css({position:"absolute",top:"0px",left:"0px"});var h=e.css("position");e.css("position","relative");a.appendTo(e);var i=a.offset().top;g=g.offset().top-i;a.remove();
|
||||
e.css("position",h);e.animate({scrollTop:g+"px"},d.duration,d.easing,function(j){if(c.length===0)typeof d.callback==="function"&&d.callback.apply(this,[j]);else f.scroll(c,d);return true});return true},fn:function(c){var d=b.ScrollTo,f=b(this);if(f.length===0)return this;var a=f.parent(),e=[];for(config=b.extend({},d.config,c);a.length===1&&!a.is("body")&&a.get(0)!==document;){c=a.get(0);if(a.css("overflow-y")!=="visible"&&c.scrollHeight!==c.clientHeight){e.push({$container:a,$target:f});f=a}a=a.parent()}e.push({$container:b(b.browser.msie?
|
||||
"html":"body"),$target:f});if(config.durationMode==="all")config.duration/=e.length;d.scroll(e,config);return this},construct:function(c){var d=b.ScrollTo;b.fn.ScrollTo=d.fn;d.config=b.extend(d.config,c);return this}};b.ScrollTo.construct()}})(jQuery);
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Learning SBT
|
||||
tagline: From Basics to Wizardry
|
||||
description: |
|
||||
We highly recommend trying the [Getting Started Guide](https://github.com/harrah/xsbt/wiki/Getting-Started-Welcome)
|
||||
before diving into sbt. There are also a lot of great introductory [talks](talks.html) available for your viewing pleasure.
|
||||
toplinks:
|
||||
- name: 'Getting Started Guide'
|
||||
link: 'https://github.com/harrah/xsbt/wiki/Getting-Started-Welcome'
|
||||
- name: 'How to ...'
|
||||
link: 'howto.html'
|
||||
- name: 'Talks'
|
||||
link: 'talks.html'
|
||||
- name: 'Wiki'
|
||||
link: 'https://github.com/harrah/xsbt/wiki'
|
||||
- name: 'Plugins'
|
||||
link: 'plugins.html'
|
||||
- name: 'FAQ'
|
||||
link: 'https://github.com/harrah/xsbt/wiki/FAQ'
|
||||
---
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
---
|
||||
layout: content
|
||||
title: Community Repository Policy
|
||||
---
|
||||
|
||||
|
||||
The community repository has the following guideline for artifacts published to it:
|
||||
|
||||
1. All pubished artifacts are the authors own work or have an appropriate license which grants distribution rights.
|
||||
|
||||
2. All published artifacts come from open source projects, that have an open patch acceptance policy.
|
||||
|
||||
3. All published artifacts are placed under an organization in a DNS domain for which you have the permission to use or are an owner (scala-sbt.org is available for SBT plugins).
|
||||
|
||||
4. All published artifacts are signed by a committer of the project (coming soon).
|
||||
|
|
@ -1,284 +0,0 @@
|
|||
html,body,div,span,applet,object,iframe,h1,h2,h3,h5,h6,p,blockquote,pre,a,abbr,acronym,address,big,cite,del,dfn,em,img,ins,kbd,q,s,samp,small,strike,strong,sub,sup,tt,var,b,u,i,center,dl,dt,dd,ol,li,fieldset,form,label,legend,table,caption,tbody,tfoot,thead,tr,th,td,article,aside,canvas,details,embed,figure,figcaption,footer,header,hgroup,menu,nav,output,ruby,section,summary,time,mark,audio,video{margin:0;padding:0;border:0;font-size:100%;font:inherit;vertical-align:baseline}
|
||||
|
||||
ul {margin:0;border:0;font-size:100%;font:inherit;vertical-align:baseline}
|
||||
code {padding:0;border:0;font-size:100%;vertical-align:baseline}
|
||||
|
||||
article,aside,details,figcaption,figure,footer,header,hgroup,menu,nav,section{display:block}
|
||||
blockquote,q{quotes:none}
|
||||
blockquote:before,blockquote:after,q:before,q:after{content:'';content:none}
|
||||
table{border-collapse:collapse;border-spacing:0}
|
||||
.cf:before,.cf:after{content:"";display:table}
|
||||
.cf:after{clear:both}
|
||||
.cf{zoom:1}
|
||||
|
||||
body, html {
|
||||
font-family: sans-serif;
|
||||
height:100%;
|
||||
}
|
||||
|
||||
a:link, a:visited {
|
||||
color:#2EABFF;/*15f*/
|
||||
padding-left:4px;
|
||||
text-decoration:none;
|
||||
}
|
||||
|
||||
a.scala:link, a.scala:visited {
|
||||
color:#FF0000;
|
||||
}
|
||||
|
||||
p {
|
||||
margin-bottom:.5em;
|
||||
}
|
||||
|
||||
h1 { font-size:130px; line-height:1em; }
|
||||
|
||||
h2 { color:#bbb; font-size:2.5em; }
|
||||
|
||||
h3 { font-size:1.75em; line-height:1.5em; }
|
||||
|
||||
h4 { font:inherit; }
|
||||
h4 { font-size:1.5em;margin:1.3em 0em 0.7em 0em;padding:0;border:0;vertical-align:baseline }
|
||||
|
||||
li { margin:0.5em 0; }
|
||||
|
||||
#more {
|
||||
background:#576369; position:fixed;
|
||||
left:0; right:0; top:0; z-index:9999;
|
||||
padding:0 0 .25em 0;
|
||||
font-family: 'Lucida Grande', 'Helvetica', sans-serif; /* for consistency with rest of site */
|
||||
font-size:24px;
|
||||
text-shadow:0 1px #333;
|
||||
-moz-box-shadow:0px 2px 2px #ccc;
|
||||
-webkit-box-shadow:0px 2px 2px #ccc;
|
||||
box-shadow:0px 2px 2px #ccc;
|
||||
filter: progid:DXImageTransform.Microsoft.Shadow(strength=2, direction=180, color='#cccccc');
|
||||
-ms-filter: "progid:DXImageTransform.Microsoft.Shadow(strength=2, Direction=180, Color='#cccccc')";
|
||||
}
|
||||
|
||||
#more-hand, #top { color:#eee; margin:.25em .5em 0 .5em; }
|
||||
|
||||
a#get-launcher:link, a#get-launcher:visited {
|
||||
border-left:0;
|
||||
-moz-box-shadow:0px 0px 4px #333333;
|
||||
-webkit-box-shadow:0px 0px 4px #333333;
|
||||
box-shadow:0px 0px 4px #333333;
|
||||
}
|
||||
|
||||
#head, #feature-list, .feature h3, .feature .line, #foot .content, .ita, #install-info-content, .contained {
|
||||
width:940px; margin:0 auto;
|
||||
}
|
||||
ul#section-toc {
|
||||
list-style:none;
|
||||
margin-bottom:2em;
|
||||
}
|
||||
|
||||
#intro { padding:1em 0 0 0; text-align:left; height:100%; }
|
||||
|
||||
#head { border-bottom:1px solid #eee; }
|
||||
|
||||
#name { width:50%; }
|
||||
|
||||
#vc { }
|
||||
.page-description { margin-top:100px; width: 50%;}
|
||||
#start { font-size:50px; margin-top:100px; }
|
||||
#start em { font-weight:bold; font-size:55px; }
|
||||
#install-primary { margin-top:.75em;}
|
||||
#install-extra { font-size: 70%; color:#bbb; margin-top:.5em; }
|
||||
#install-info {
|
||||
background:#576369
|
||||
}
|
||||
#install-info-content {
|
||||
color:#eee;
|
||||
display:none;
|
||||
font-size:70%;
|
||||
line-height:1.5em;
|
||||
padding:1em 0;
|
||||
text-shadow:0 1px #000;
|
||||
}
|
||||
|
||||
#nix, #win {
|
||||
display:none;
|
||||
margin-top:1em;
|
||||
}
|
||||
|
||||
#what { font-size:120%; line-height:1.4em; margin:0 0 1em 0; }
|
||||
|
||||
#features ul { list-style:none; }
|
||||
#pagecontent { margin: 0 auto; width: 940px; }
|
||||
#subscribe, #wiki, #src, #list { margin:0 0 .5em 0;}
|
||||
|
||||
#install {
|
||||
float:right;
|
||||
margin:.25em .5em 0 0;
|
||||
}
|
||||
|
||||
.container-spacer { line-height: 40px; }
|
||||
.download.btn span {
|
||||
color:#fff;
|
||||
text-shadow:0 1px #bbb;
|
||||
}
|
||||
|
||||
.download.btn {
|
||||
background:#83F537;
|
||||
filter: progid:DXImageTransform.Microsoft.gradient(
|
||||
startColorstr='#12E3FF', endColorstr='#28D7FA');
|
||||
background: -webkit-gradient(linear, left top, left bottom,
|
||||
from(#12E3FF), to(#28D7FA));
|
||||
background: -moz-linear-gradient(top, #12E3FF, #28D7FA);
|
||||
border:1px solid #28D7FA;
|
||||
color:#333;
|
||||
text-shadow:0 1px #eee;
|
||||
}
|
||||
|
||||
.download.btn:hover {
|
||||
background:#83F537;
|
||||
filter: progid:DXImageTransform.Microsoft.gradient(
|
||||
startColorstr='#4CD6F1', endColorstr='#00D4FF');
|
||||
background: -webkit-gradient(linear, left top, left bottom,
|
||||
from(#4CD6F1), to(#00D4FF));
|
||||
background: -moz-linear-gradient(top, #4CD6F1, #00D4FF);
|
||||
border:1px solid #28D7FA;
|
||||
}
|
||||
|
||||
#more-hand { float:left; clear:both; }
|
||||
#top { width:700px; margin:.25em auto; }
|
||||
|
||||
#top h3 a, #top .brand {
|
||||
float: left;
|
||||
display: block;
|
||||
padding: 8px 20px 12px;
|
||||
color: white;
|
||||
font-size: 19px;
|
||||
font-weight: 200;
|
||||
line-height: 1;
|
||||
}
|
||||
|
||||
#top a {
|
||||
color: #BFBFBF;
|
||||
text-shadow: 0 -1px 0 rgba(0, 0, 0, 0.25);
|
||||
}
|
||||
|
||||
#top a:hover {
|
||||
color:#fff;
|
||||
}
|
||||
|
||||
#topbar div > ul a, .nav a {
|
||||
display: block;
|
||||
float: none;
|
||||
padding: 6px 6px 7px;
|
||||
line-height: 19px;
|
||||
text-decoration: none;
|
||||
margin-top:.2em;
|
||||
}
|
||||
|
||||
#top div > ul > li, .nav > li {
|
||||
display: block;
|
||||
float: left;
|
||||
}
|
||||
|
||||
#top div > ul, .nav {
|
||||
padding: 0;
|
||||
display: block;
|
||||
float: left;
|
||||
margin: 0 10px 0 0;
|
||||
position: relative;
|
||||
left: 0;
|
||||
list-style: disc;
|
||||
}
|
||||
|
||||
.nav li {
|
||||
margin: 0;
|
||||
}
|
||||
|
||||
#top li {
|
||||
font-size: 14px;
|
||||
}
|
||||
|
||||
#info { display:none; }
|
||||
#info a { padding-left: .25em; }
|
||||
|
||||
#extra { height: 100%; }
|
||||
#examples {
|
||||
font-size:.9em;
|
||||
margin:.5em 0 0 0;
|
||||
line-height:1.5em;
|
||||
}
|
||||
|
||||
.ita {
|
||||
text-align:right;
|
||||
}
|
||||
|
||||
#foot {
|
||||
background: #576369;
|
||||
color:#eee;
|
||||
font-size:smaller;
|
||||
padding:1em 0;
|
||||
}
|
||||
|
||||
.line {
|
||||
margin:.5em 0 0 0;
|
||||
padding:.25em 0;
|
||||
}
|
||||
|
||||
.line p {
|
||||
border-left:10px solid #eee;
|
||||
padding-left:.5em;
|
||||
}
|
||||
|
||||
.feature {
|
||||
padding:1.5em .25em;
|
||||
margin:1em auto;
|
||||
}
|
||||
|
||||
.feature .more {
|
||||
padding:.25em .25em 0 .25em;
|
||||
}
|
||||
|
||||
#info-left { margin-right:1em; }
|
||||
|
||||
#info-left, #info-right { float: left; }
|
||||
|
||||
input[type="text"] {
|
||||
font-family: 'Copse', serif;
|
||||
font-size:22px; padding:.25em;
|
||||
color:#bbb;
|
||||
margin-left:5px;
|
||||
}
|
||||
|
||||
.left {
|
||||
float:left;
|
||||
}
|
||||
|
||||
.btn {
|
||||
border:1px solid #bbb;
|
||||
background:#eee;
|
||||
padding:.25em .5em;
|
||||
font-size:18px;
|
||||
-webkit-border-radius: 5px;
|
||||
-moz-border-radius: 5px;
|
||||
border-radius: 5px;
|
||||
background: #eee;
|
||||
text-shadow:0 1px #fff;
|
||||
filter: progid:DXImageTransform.Microsoft.gradient(
|
||||
startColorstr='#eeeeee', endColorstr='#D1D1D1');
|
||||
background: -webkit-gradient(linear, left top,
|
||||
left bottom, from(#eeeeee),
|
||||
to(#D1D1D1));
|
||||
background: -moz-linear-gradient(top, #eeeeee, #D1D1D1);
|
||||
margin:5px 0;
|
||||
}
|
||||
|
||||
pre {
|
||||
white-space:pre-wrap;
|
||||
font-size: 16px;
|
||||
font-weight: normal;
|
||||
margin:.7em 0;
|
||||
padding: 6px 10px;
|
||||
border:1px solid #bbb;
|
||||
-webkit-border-radius: 4x;
|
||||
-moz-border-radius: 4px;
|
||||
border-radius: 4px;
|
||||
color:rgb(48,48,48);
|
||||
background-color:rgb(248, 248, 248);
|
||||
|
||||
}
|
||||
|
|
@ -1,279 +0,0 @@
|
|||
html,body,div,span,applet,object,iframe,h1,h2,h3,h4,h5,h6,p,blockquote,pre,a,abbr,acronym,address,big,cite,code,del,dfn,em,img,ins,kbd,q,s,samp,small,strike,strong,sub,sup,tt,var,b,u,i,center,dl,dt,dd,ol,ul,li,fieldset,form,label,legend,table,caption,tbody,tfoot,thead,tr,th,td,article,aside,canvas,details,embed,figure,figcaption,footer,header,hgroup,menu,nav,output,ruby,section,summary,time,mark,audio,video{margin:0;padding:0;border:0;font-size:100%;font:inherit;vertical-align:baseline}article,aside,details,figcaption,figure,footer,header,hgroup,menu,nav,section{display:block}body{line-height:1}ol,ul{list-style:none}blockquote,q{quotes:none}blockquote:before,blockquote:after,q:before,q:after{content:'';content:none}table{border-collapse:collapse;border-spacing:0}
|
||||
.cf:before,.cf:after{content:"";display:table}.cf:after{clear:both}.cf{zoom:1}
|
||||
|
||||
body, html {
|
||||
font-family: 'Lucida Grande', 'Helvetica', sans-serif;
|
||||
font-size:24px;
|
||||
height:100%;
|
||||
}
|
||||
|
||||
a:link, a:visited {
|
||||
color:#2EABFF;/*15f*/
|
||||
padding-left:4px;
|
||||
text-decoration:none;
|
||||
}
|
||||
|
||||
a.scala:link, a.scala:visited {
|
||||
color:#FF0000;
|
||||
}
|
||||
|
||||
p {
|
||||
margin-bottom:.5em;
|
||||
}
|
||||
|
||||
h1, h2, h3, h4, h5, #name, #vc { font-family: 'Copse', serif; }
|
||||
|
||||
h1 { font-size:130px; line-height:1em; }
|
||||
|
||||
h2 { color:#bbb; font-size:2.5em; }
|
||||
|
||||
h3 { font-size:2em; line-height:1.5em; }
|
||||
|
||||
h4 { font-size:1.75em; line-height:1.5em; }
|
||||
|
||||
li { margin:1em 0; }
|
||||
|
||||
#more {
|
||||
background:#576369; position:fixed;
|
||||
left:0; right:0; top:0; z-index:9999;
|
||||
padding:0 0 .25em 0;
|
||||
text-shadow:0 1px #333;
|
||||
-moz-box-shadow:0px 2px 2px #ccc;
|
||||
-webkit-box-shadow:0px 2px 2px #ccc;
|
||||
box-shadow:0px 2px 2px #ccc;
|
||||
filter: progid:DXImageTransform.Microsoft.Shadow(strength=2, direction=180, color='#cccccc');
|
||||
-ms-filter: "progid:DXImageTransform.Microsoft.Shadow(strength=2, Direction=180, Color='#cccccc')";
|
||||
}
|
||||
|
||||
#more-hand, #top { color:#eee; margin:.25em .5em 0 .5em; }
|
||||
|
||||
a#get-launcher:link, a#get-launcher:visited {
|
||||
border-left:0;
|
||||
-moz-box-shadow:0px 0px 4px #333333;
|
||||
-webkit-box-shadow:0px 0px 4px #333333;
|
||||
box-shadow:0px 0px 4px #333333;
|
||||
}
|
||||
|
||||
#head, #feature-list, .feature h3, .feature .line, #foot .content, .ita, #install-info-content, .contained {
|
||||
width:940px; margin:0 auto;
|
||||
}
|
||||
|
||||
#features {
|
||||
font-size: 80%;
|
||||
margin:1em 0;
|
||||
}
|
||||
|
||||
#intro { padding:2em 0 0 0; text-align:left; height:100%; }
|
||||
#intro p { line-height:1.5em; }
|
||||
|
||||
#head { border-bottom:1px solid #eee; }
|
||||
|
||||
#name { width:50%; }
|
||||
|
||||
#vc { }
|
||||
.page-description { margin-top:100px; width: 50%;}
|
||||
#start { font-size:50px; margin-top:100px; }
|
||||
#start em { font-weight:bold; font-size:55px; }
|
||||
#install-primary { margin-top:.75em;}
|
||||
#install-extra { font-size: 70%; color:#bbb; margin-top:.5em; }
|
||||
#install-info {
|
||||
background:#576369
|
||||
}
|
||||
#install-info-content {
|
||||
color:#eee;
|
||||
display:none;
|
||||
font-size:70%;
|
||||
line-height:1.5em;
|
||||
padding:1em 0;
|
||||
text-shadow:0 1px #000;
|
||||
}
|
||||
|
||||
#nix, #win {
|
||||
display:none;
|
||||
margin-top:1em;
|
||||
}
|
||||
|
||||
#what { font-size:120%; line-height:1.4em; margin:0 0 1em 0; }
|
||||
|
||||
#features ul { list-style:none; width:50%; }
|
||||
#pagecontent { margin: 0 auto; width: 940px; }
|
||||
#subscribe, #wiki, #src, #list { margin:0 0 .5em 0;}
|
||||
|
||||
#install {
|
||||
float:right;
|
||||
margin:.25em .5em 0 0;
|
||||
}
|
||||
|
||||
.container-spacer { line-height: 40px; }
|
||||
.download.btn span {
|
||||
color:#fff;
|
||||
text-shadow:0 1px #bbb;
|
||||
}
|
||||
|
||||
.download.btn {
|
||||
background:#83F537;
|
||||
filter: progid:DXImageTransform.Microsoft.gradient(
|
||||
startColorstr='#12E3FF', endColorstr='#28D7FA');
|
||||
background: -webkit-gradient(linear, left top, left bottom,
|
||||
from(#12E3FF), to(#28D7FA));
|
||||
background: -moz-linear-gradient(top, #12E3FF, #28D7FA);
|
||||
border:1px solid #28D7FA;
|
||||
color:#333;
|
||||
text-shadow:0 1px #eee;
|
||||
}
|
||||
|
||||
.download.btn:hover {
|
||||
background:#83F537;
|
||||
filter: progid:DXImageTransform.Microsoft.gradient(
|
||||
startColorstr='#4CD6F1', endColorstr='#00D4FF');
|
||||
background: -webkit-gradient(linear, left top, left bottom,
|
||||
from(#4CD6F1), to(#00D4FF));
|
||||
background: -moz-linear-gradient(top, #4CD6F1, #00D4FF);
|
||||
border:1px solid #28D7FA;
|
||||
}
|
||||
|
||||
#more-hand { float:left; clear:both; }
|
||||
#top { width:700px; margin:.25em auto; }
|
||||
|
||||
#top h3 a, #top .brand {
|
||||
float: left;
|
||||
display: block;
|
||||
padding: 8px 20px 12px;
|
||||
color: white;
|
||||
font-size: 19px;
|
||||
font-weight: 200;
|
||||
line-height: 1;
|
||||
}
|
||||
|
||||
#top a {
|
||||
color: #BFBFBF;
|
||||
text-shadow: 0 -1px 0 rgba(0, 0, 0, 0.25);
|
||||
}
|
||||
|
||||
#top a:hover {
|
||||
color:#fff;
|
||||
}
|
||||
|
||||
#topbar div > ul a, .nav a {
|
||||
display: block;
|
||||
float: none;
|
||||
padding: 6px 6px 7px;
|
||||
line-height: 19px;
|
||||
text-decoration: none;
|
||||
margin-top:.2em;
|
||||
}
|
||||
|
||||
#top div > ul > li, .nav > li {
|
||||
display: block;
|
||||
float: left;
|
||||
}
|
||||
|
||||
#top div > ul, .nav {
|
||||
display: block;
|
||||
float: left;
|
||||
margin: 0 10px 0 0;
|
||||
position: relative;
|
||||
left: 0;
|
||||
list-style: disc;
|
||||
}
|
||||
|
||||
.nav li {
|
||||
margin: 0;
|
||||
}
|
||||
|
||||
#top li {
|
||||
font-size: 14px;
|
||||
}
|
||||
|
||||
#info { display:none; }
|
||||
#info a { padding-left: .25em; }
|
||||
|
||||
#extra { height: 100%; }
|
||||
#examples {
|
||||
font-size:.9em;
|
||||
margin:.5em 0 0 0;
|
||||
line-height:1.5em;
|
||||
}
|
||||
|
||||
.ita {
|
||||
text-align:right;
|
||||
}
|
||||
|
||||
#foot {
|
||||
background: #576369;
|
||||
color:#eee;
|
||||
font-size:smaller;
|
||||
padding:1em 0;
|
||||
}
|
||||
|
||||
.line {
|
||||
margin:.5em 0 0 0;
|
||||
padding:.25em 0;
|
||||
}
|
||||
|
||||
.line p {
|
||||
border-left:10px solid #eee;
|
||||
padding-left:.5em;
|
||||
}
|
||||
|
||||
.feature {
|
||||
padding:1.5em .25em;
|
||||
margin:1em auto;
|
||||
}
|
||||
|
||||
.feature .more {
|
||||
padding:.25em .25em 0 .25em;
|
||||
}
|
||||
|
||||
#info-left { margin-right:1em; }
|
||||
|
||||
#info-left, #info-right { float: left; }
|
||||
|
||||
input[type="text"] {
|
||||
font-family: 'Copse', serif;
|
||||
font-size:22px; padding:.25em;
|
||||
color:#bbb;
|
||||
margin-left:5px;
|
||||
}
|
||||
|
||||
.left {
|
||||
float:left;
|
||||
}
|
||||
|
||||
.btn {
|
||||
border:1px solid #bbb;
|
||||
background:#eee;
|
||||
padding:.25em .5em;
|
||||
font-size:18px;
|
||||
-webkit-border-radius: 5px;
|
||||
-moz-border-radius: 5px;
|
||||
border-radius: 5px;
|
||||
background: #eee;
|
||||
text-shadow:0 1px #fff;
|
||||
filter: progid:DXImageTransform.Microsoft.gradient(
|
||||
startColorstr='#eeeeee', endColorstr='#D1D1D1');
|
||||
background: -webkit-gradient(linear, left top,
|
||||
left bottom, from(#eeeeee),
|
||||
to(#D1D1D1));
|
||||
background: -moz-linear-gradient(top, #eeeeee, #D1D1D1);
|
||||
margin:5px 0;
|
||||
}
|
||||
|
||||
pre {
|
||||
white-space:pre-wrap;
|
||||
text-shadow:0 1px 1px rgba(0, 0, 0, 0.5);
|
||||
font-family:'Copse', serif;
|
||||
font-size: 16px;
|
||||
font-weight: normal;
|
||||
margin:.5em 0;
|
||||
padding:.25em;
|
||||
border:1px solid #bbb;
|
||||
-webkit-border-radius: 10px;
|
||||
-moz-border-radius: 10px;
|
||||
border-radius: 10px;
|
||||
background-image:linear-gradient(rgba(0, 0, 0, 0.5), rgba(0, 0, 0, 0));
|
||||
color:#fff;
|
||||
background-color:rgba(0, 0, 0, 0.5);
|
||||
-webkit-box-shadow:inset 0 1px 3px rgba(0, 0, 0, 0.5), 0 1px 0 rgba(255, 255, 255, 0.5);
|
||||
box-shadow:inset 0 1px 3px rgba(0, 0, 0, 0.5), 0 1px 0 rgba(255, 255, 255, 0.5);
|
||||
}
|
||||
|
|
@ -1,63 +0,0 @@
|
|||
/* manni style for pygmentize with .go darkened */
|
||||
|
||||
.hll { background-color: #ffffcc }
|
||||
.c { color: #0099FF; font-style: italic } /* Comment */
|
||||
.err { color: #AA0000; background-color: #FFAAAA } /* Error */
|
||||
.k { color: #006699; font-weight: bold } /* Keyword */
|
||||
.o { color: #555555 } /* Operator */
|
||||
.cm { color: #0099FF; font-style: italic } /* Comment.Multiline */
|
||||
.cp { color: #009999 } /* Comment.Preproc */
|
||||
.c1 { color: #0099FF; font-style: italic } /* Comment.Single */
|
||||
.cs { color: #0099FF; font-weight: bold; font-style: italic } /* Comment.Special */
|
||||
.gd { background-color: #FFCCCC; border: 1px solid #CC0000 } /* Generic.Deleted */
|
||||
.ge { font-style: italic } /* Generic.Emph */
|
||||
.gr { color: #FF0000 } /* Generic.Error */
|
||||
.gh { color: #003300; font-weight: bold } /* Generic.Heading */
|
||||
.gi { background-color: #CCFFCC; border: 1px solid #00CC00 } /* Generic.Inserted */
|
||||
.go { color: #333333; } /* Generic.Output */
|
||||
.gp { color: #000099; font-weight: bold } /* Generic.Prompt */
|
||||
.gs { font-weight: bold } /* Generic.Strong */
|
||||
.gu { color: #003300; font-weight: bold } /* Generic.Subheading */
|
||||
.gt { color: #99CC66 } /* Generic.Traceback */
|
||||
.kc { color: #006699; font-weight: bold } /* Keyword.Constant */
|
||||
.kd { color: #006699; font-weight: bold } /* Keyword.Declaration */
|
||||
.kn { color: #006699; font-weight: bold } /* Keyword.Namespace */
|
||||
.kp { color: #006699 } /* Keyword.Pseudo */
|
||||
.kr { color: #006699; font-weight: bold } /* Keyword.Reserved */
|
||||
.kt { color: #007788; font-weight: bold } /* Keyword.Type */
|
||||
.m { color: #FF6600 } /* Literal.Number */
|
||||
.s { color: #CC3300 } /* Literal.String */
|
||||
.na { color: #330099 } /* Name.Attribute */
|
||||
.nb { color: #336666 } /* Name.Builtin */
|
||||
.nc { color: #00AA88; font-weight: bold } /* Name.Class */
|
||||
.no { color: #336600 } /* Name.Constant */
|
||||
.nd { color: #9999FF } /* Name.Decorator */
|
||||
.ni { color: #999999; font-weight: bold } /* Name.Entity */
|
||||
.ne { color: #CC0000; font-weight: bold } /* Name.Exception */
|
||||
.nf { color: #CC00FF } /* Name.Function */
|
||||
.nl { color: #9999FF } /* Name.Label */
|
||||
.nn { color: #00CCFF; font-weight: bold } /* Name.Namespace */
|
||||
.nt { color: #330099; font-weight: bold } /* Name.Tag */
|
||||
.nv { color: #003333 } /* Name.Variable */
|
||||
.ow { color: #000000; font-weight: bold } /* Operator.Word */
|
||||
.w { color: #bbbbbb } /* Text.Whitespace */
|
||||
.mf { color: #FF6600 } /* Literal.Number.Float */
|
||||
.mh { color: #FF6600 } /* Literal.Number.Hex */
|
||||
.mi { color: #FF6600 } /* Literal.Number.Integer */
|
||||
.mo { color: #FF6600 } /* Literal.Number.Oct */
|
||||
.sb { color: #CC3300 } /* Literal.String.Backtick */
|
||||
.sc { color: #CC3300 } /* Literal.String.Char */
|
||||
.sd { color: #CC3300; font-style: italic } /* Literal.String.Doc */
|
||||
.s2 { color: #CC3300 } /* Literal.String.Double */
|
||||
.se { color: #CC3300; font-weight: bold } /* Literal.String.Escape */
|
||||
.sh { color: #CC3300 } /* Literal.String.Heredoc */
|
||||
.si { color: #AA0000 } /* Literal.String.Interpol */
|
||||
.sx { color: #CC3300 } /* Literal.String.Other */
|
||||
.sr { color: #33AAAA } /* Literal.String.Regex */
|
||||
.s1 { color: #CC3300 } /* Literal.String.Single */
|
||||
.ss { color: #FFCC33 } /* Literal.String.Symbol */
|
||||
.bp { color: #336666 } /* Name.Builtin.Pseudo */
|
||||
.vc { color: #003333 } /* Name.Variable.Class */
|
||||
.vg { color: #003333 } /* Name.Variable.Global */
|
||||
.vi { color: #003333 } /* Name.Variable.Instance */
|
||||
.il { color: #FF6600 } /* Literal.Number.Integer.Long */
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Talks
|
||||
tagline: People presenting SBT topics
|
||||
description: "This page contains a list of presentations about SBT. If you know about a presentation that isn't on the list please open an issue [https://github.com/sbt/sbt.github.com](https://github.com/sbt/sbt.github.com)."
|
||||
toplinks: #Links at the top.
|
||||
|
||||
- name: 'Building SBT Plugins'
|
||||
id: 'buildingsbtplugins'
|
||||
content: |
|
||||
#### Building SBT Plugins ####
|
||||
Presentation showing how to build SBT plugins. The source code and presentation pdf
|
||||
can be found [here](https://github.com/mads379/sbt-plugin-examples "here").
|
||||
- name: 'SBT Cookbook'
|
||||
id: 'sbtcookbook'
|
||||
content: |
|
||||
#### SBT Cookbook ####
|
||||
A [talk](http://youtu.be/V2rl62CZPVc) on the basics of SBT as well as some cookbook examples.
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,191 +0,0 @@
|
|||
---
|
||||
layout: content
|
||||
title: Deploying to Sonatype
|
||||
---
|
||||
|
||||
Deploying to sonatype is easy! Just follow these simple steps:
|
||||
|
||||
## First - PGP Signatures ##
|
||||
|
||||
You'll need to PGP sign your artifacts for the Sonatype repository. Don't worry, there's a [plugin for that](http://scala-sbt.org/xsbt-gpg-plugin). Follow the instructions for the plugin and you'll have PGP signed artifacts in no time.
|
||||
|
||||
*Note: The plugin is a jvm-only solution to generate PGP keys and sign artifacts. It can work with the GPG command line tool, but the command line is not needed.*
|
||||
|
||||
|
||||
## Second - Maven Publishing Settings ##
|
||||
|
||||
To publish to a maven repository, you'll need to configure a few settings so that the correct metadata is generated.
|
||||
|
||||
|
||||
publishMavenStyle := true
|
||||
|
||||
|
||||
is used to ensure POMs are generated and pushed. Next, you have to set up the repositories you wish to push too. Luckily, Sonatype's OSSRH uses the same URLs for everyone:
|
||||
|
||||
publishTo <<= version { (v: String) =>
|
||||
val nexus = "https://oss.sonatype.org/"
|
||||
if (v.trim.endsWith("SNAPSHOT"))
|
||||
Some("snapshots" at nexus + "content/repositories/snapshots")
|
||||
else
|
||||
Some("releases" at nexus + "service/local/staging/deploy/maven2")
|
||||
}
|
||||
|
||||
Another good idea is to not publish your test artifacts:
|
||||
|
||||
publishArtifact in Test := false
|
||||
|
||||
## Third - POM Metadata ##
|
||||
|
||||
Now, we want to control what's available in the `pom.xml` file. This file describes our project in the maven repository and is used by indexing services for search and discover. This means it's important that `pom.xml` should have all information we wish to advertise as well as required info!
|
||||
|
||||
First, let's make sure no repositories show up in the POM file. To publish on maven-central, all *required* artifacts must also be hosted on maven central. However, sometimes we have optional dependencies for special features. If that's the case, let's remove the repositories for optional dependencies in our artifact:
|
||||
|
||||
pomIncludeRepository := { _ => false }
|
||||
|
||||
Next, the POM metadata that isn't generated by SBT must be added. This is done through the `pomExtra` configuration option:
|
||||
|
||||
pomExtra := (
|
||||
<url>http://jsuereth.com/scala-arm</url>
|
||||
<licenses>
|
||||
<license>
|
||||
<name>BSD-style</name>
|
||||
<url>http://www.opensource.org/licenses/bsd-license.php</url>
|
||||
<distribution>repo</distribution>
|
||||
</license>
|
||||
</licenses>
|
||||
<scm>
|
||||
<url>git@github.com:jsuereth/scala-arm.git</url>
|
||||
<connection>scm:git:git@github.com:jsuereth/scala-arm.git</connection>
|
||||
</scm>
|
||||
<developers>
|
||||
<developer>
|
||||
<id>jsuereth</id>
|
||||
<name>Josh Suereth</name>
|
||||
<url>http://jsuereth.com</url>
|
||||
</developer>
|
||||
</developers>)
|
||||
|
||||
Specifically, the `url`, `license`, `scm.url`, `scm.connection` and `developer` sections are required. The above is an example from the [scala-arm](http://jsuereth.com/scala-arm) project.
|
||||
|
||||
*Note* that sbt will automatically inject `licenses` and `url` nodes if they are already present in your build file. Thus an alternative to the above `pomExtra` is to include the following entries:
|
||||
|
||||
licenses := Seq("BSD-style" -> url("http://www.opensource.org/licenses/bsd-license.php"))
|
||||
|
||||
homepage := Some(url("http://jsuereth.com/scala-arm"))
|
||||
|
||||
This might be advantageous if those keys are used also by other plugins (e.g. `ls`). You **cannot use both** the sbt `licenses` key and the `licenses` section in `pomExtra` at the same time, as this will produce duplicate entries in the final POM file, leading to a rejection in Sonatype's staging process.
|
||||
|
||||
*The full format of a pom.xml file is [outlined here](http://maven.apache.org/pom.html).*
|
||||
|
||||
## Fourth - Adding credentials ##
|
||||
|
||||
The credentials for your Sonatype OSSRH account need to be added somewhere. Common convention is a `~/.sbt/sonatype.sbt` file with the following:
|
||||
|
||||
credentials += Credentials("Sonatype Nexus Repository Manager",
|
||||
"oss.sonatype.org",
|
||||
"<your username>",
|
||||
"<your password>")
|
||||
|
||||
*Note: The first two strings must be `"Sonatype Nexus Repository Manager"` and `"oss.sonatype.org"` for Ivy to use the credentials.*
|
||||
|
||||
## Finally - Publish ##
|
||||
|
||||
In SBT, run `publish` and you should see something like the following:
|
||||
|
||||
> publish
|
||||
Please enter your PGP passphrase> ***********
|
||||
[info] Packaging /home/josh/projects/typesafe/scala-arm/target/scala-2.9.1/scala-arm_2.9.1-1.2.jar ...
|
||||
[info] Wrote /home/josh/projects/typesafe/scala-arm/target/scala-2.9.1/scala-arm_2.9.1-1.2.pom
|
||||
[info] Packaging /home/josh/projects/typesafe/scala-arm/target/scala-2.9.1/scala-arm_2.9.1-1.2-javadoc.jar ...
|
||||
[info] Packaging /home/josh/projects/typesafe/scala-arm/target/scala-2.9.1/scala-arm_2.9.1-1.2-sources.jar ...
|
||||
[info] :: delivering :: com.jsuereth#scala-arm_2.9.1;1.2 :: 1.2 :: release :: Mon Jan 23 13:16:57 EST 2012
|
||||
[info] Done packaging.
|
||||
[info] Done packaging.
|
||||
[info] Done packaging.
|
||||
[info] delivering ivy file to /home/josh/projects/typesafe/scala-arm/target/scala-2.9.1/ivy-1.2.xml
|
||||
[info] published scala-arm_2.9.1 to https://oss.sonatype.org/service/local/staging/deploy/maven2/com/jsuereth/scala-arm_2.9.1/1.2/scala-arm_2.9.1-1.2-sources.jar
|
||||
[info] published scala-arm_2.9.1 to https://oss.sonatype.org/service/local/staging/deploy/maven2/com/jsuereth/scala-arm_2.9.1/1.2/scala-arm_2.9.1-1.2-javadoc.jar.asc
|
||||
[info] published scala-arm_2.9.1 to https://oss.sonatype.org/service/local/staging/deploy/maven2/com/jsuereth/scala-arm_2.9.1/1.2/scala-arm_2.9.1-1.2-sources.jar.asc
|
||||
[info] published scala-arm_2.9.1 to https://oss.sonatype.org/service/local/staging/deploy/maven2/com/jsuereth/scala-arm_2.9.1/1.2/scala-arm_2.9.1-1.2.jar
|
||||
[info] published scala-arm_2.9.1 to https://oss.sonatype.org/service/local/staging/deploy/maven2/com/jsuereth/scala-arm_2.9.1/1.2/scala-arm_2.9.1-1.2.jar.asc
|
||||
[info] published scala-arm_2.9.1 to https://oss.sonatype.org/service/local/staging/deploy/maven2/com/jsuereth/scala-arm_2.9.1/1.2/scala-arm_2.9.1-1.2.pom.asc
|
||||
[info] published scala-arm_2.9.1 to https://oss.sonatype.org/service/local/staging/deploy/maven2/com/jsuereth/scala-arm_2.9.1/1.2/scala-arm_2.9.1-1.2.pom
|
||||
[info] published scala-arm_2.9.1 to https://oss.sonatype.org/service/local/staging/deploy/maven2/com/jsuereth/scala-arm_2.9.1/1.2/scala-arm_2.9.1-1.2-javadoc.jar
|
||||
[success] Total time: 9 s, completed Jan 23, 2012 1:17:03 PM
|
||||
|
||||
|
||||
|
||||
After publishing you have to follow the [Release workflow of nexus](https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-8.ReleaseIt). In the future, we hope to provide a Nexus SBT plugin that allows the release workflow procedures to be performed directly from SBT.
|
||||
|
||||
*Note: Staged releases allow testing across large projects of independent releases before pushing the full project.*
|
||||
|
||||
<sub>*Note:* An error message of `PGPException: checksum mismatch at 0 of 20` indicates that you got the passphrase wrong. We have found at least on OS X that there may be issues with characters outside the 7-bit ASCII range (e.g. Umlauts). If you are absolutely sure that you typed the right phrase and the error doesn't disappear, try changing the passphrase.</sub>
|
||||
|
||||
## Summary ##
|
||||
|
||||
To get your project hosted on Sonatype (and Maven Central), you will need to:
|
||||
|
||||
* Have GPG key pair, with published public key,
|
||||
* A SBT file with your Sonatype credentials *that is not pushed to the VCS*,
|
||||
* Modify `project/plugins.sbt` to include the `xsbt-gpg-plugin` to sign the artefacts,
|
||||
* Modify `build.sbt` with the required elements in the generated POM.
|
||||
|
||||
Starting with a project that is not being published, you'll need to install GPG, generate and publish your key. Swtiching to SBT,
|
||||
you'll then need to:
|
||||
|
||||
#### ~/.sbt/sonatype.sbt
|
||||
|
||||
This file (kept *outside the VCS*) contains the Sonatype credentials settings:
|
||||
|
||||
credentials += Credentials("Sonatype Nexus Repository Manager",
|
||||
"oss.sonatype.org",
|
||||
"your-sonatype-username",
|
||||
"your-sonatype-password")
|
||||
|
||||
#### project/plugins.sbt
|
||||
|
||||
This file specifies the plugins for your project. If you intend to sign the artefacts, you'll need to include @jsuereth's `xsbt-gpg-plugin`:
|
||||
|
||||
resolvers += Resolver.url("sbt-plugin-releases", /* no new line */
|
||||
new URL("http://scalasbt.artifactoryonline.com/scalasbt/sbt-plugin-releases")) /* no new line */
|
||||
(Resolver.ivyStylePatterns)
|
||||
|
||||
addSbtPlugin("com.jsuereth" % "xsbt-gpg-plugin" % "0.5")
|
||||
|
||||
#### build.sbt
|
||||
|
||||
Finally, you'll need to tweak the generated POM in your `build.sbt`. The tweaks include specifying the project's authors, URL, SCM and many others:
|
||||
|
||||
publishTo <<= version { v: String =>
|
||||
val nexus = "https://oss.sonatype.org/"
|
||||
if (v.trim.endsWith("SNAPSHOT")) Some("snapshots" at nexus + "content/repositories/snapshots")
|
||||
else Some("releases" at nexus + "service/local/staging/deploy/maven2")
|
||||
}
|
||||
|
||||
publishMavenStyle := true
|
||||
|
||||
publishArtifact in Test := false
|
||||
|
||||
pomIncludeRepository := { _ => false }
|
||||
|
||||
pomExtra := (
|
||||
<url>http://your.project.url</url>
|
||||
<licenses>
|
||||
<license>
|
||||
<name>BSD-style</name>
|
||||
<url>http://www.opensource.org/licenses/bsd-license.php</url>
|
||||
<distribution>repo</distribution>
|
||||
</license>
|
||||
</licenses>
|
||||
<scm>
|
||||
<url>git@github.com:your-account/your-project.git</url>
|
||||
<connection>scm:git:git@github.com:your-account/your-project.git</connection>
|
||||
</scm>
|
||||
<developers>
|
||||
<developer>
|
||||
<id>you</id>
|
||||
<name>Your Name</name>
|
||||
<url>http://your.url</url>
|
||||
</developer>
|
||||
</developers>
|
||||
)
|
||||
|
|
@ -1,21 +1,66 @@
|
|||
===========
|
||||
Plugin List
|
||||
===========
|
||||
=================
|
||||
Community Plugins
|
||||
=================
|
||||
|
||||
The purpose of this page is to aid developers in finding plugins that
|
||||
work with sbt 0.10+ and for plugin developers to promote their plugins
|
||||
possibly by adding some brief description.
|
||||
sbt Organization
|
||||
================
|
||||
|
||||
The `sbt organization <http://github.com/sbt>`_ is available for use by any sbt plugin.
|
||||
Developers who contribute their plugins into the community organization will still retain
|
||||
control over their repository and its access. The goal of the sbt organization is to
|
||||
organize sbt software into one central location.
|
||||
|
||||
Plugins
|
||||
-------
|
||||
A side benefit to using the sbt organization for projects is that you can use gh-pages to host websites in the http://scala-sbt.org domain.
|
||||
|
||||
Community Ivy Repository
|
||||
========================
|
||||
|
||||
`Typesafe, Inc. <http://www.typesafe.com>`_ has provided a freely available `Ivy Repository <http://scalasbt.artifactoryonline.com/scalasbt>`_ for sbt projects to use.
|
||||
If you would like to publish your project to this Ivy repository, first contact `sbt-repo-admins <http://groups.google.com/group/sbt-repo-admins?hl=en>`_ and request privileges (we have to verify code ownership, rights to publish, etc.). After which, you can deploy your plugins using the following configuration:
|
||||
|
||||
::
|
||||
|
||||
publishTo := Some(Resolver.url("sbt-plugin-releases", new URL("http://scalasbt.artifactoryonline.com/scalasbt/sbt-plugin-releases/"))(Resolver.ivyStylePatterns))
|
||||
|
||||
publishMavenStyle := false
|
||||
|
||||
You'll also need to add your credentials somewhere. For example, you might use a ``~/.sbt/sbtpluginpublish.sbt`` file:
|
||||
|
||||
::
|
||||
|
||||
credentials += Credentials("Artifactory Realm", "scalasbt.artifactoryonline.com", "jsuereth", "@my encrypted password@")
|
||||
|
||||
Where ``@my encrypted password@`` is actually obtained using the following `instructions <http://wiki.jfrog.org/confluence/display/RTF/Centrally+Secure+Passwords>`_.
|
||||
|
||||
*Note: Your code must abide by the* `repository polices <repository-rules>`_.
|
||||
|
||||
To automatically deploy snapshot/release versions of your plugin use the following configuration:
|
||||
|
||||
::
|
||||
|
||||
publishTo <<= (version) { version: String =>
|
||||
val scalasbt = "http://scalasbt.artifactoryonline.com/scalasbt/"
|
||||
val (name, url) = if (version.contains("-SNAPSHOT"))
|
||||
("sbt-plugin-snapshots", scalasbt+"sbt-plugin-snapshots")
|
||||
else
|
||||
("sbt-plugin-releases", scalasbt+"sbt-plugin-releases")
|
||||
Some(Resolver.url(name, new URL(url))(Resolver.ivyStylePatterns))
|
||||
}
|
||||
|
||||
*Note: ivy repositories currently don't support Maven-style snapshots.*
|
||||
|
||||
Available Plugins
|
||||
=================
|
||||
|
||||
Please feel free to `submit a pull request <https://github.com/harrah/xsbt/pulls>`_ that adds your plugin to the list.
|
||||
|
||||
Plugins for IDEs:
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
- IntelliJ IDEA
|
||||
- SBT Plugin to generate IDEA project configuration:
|
||||
- sbt Plugin to generate IDEA project configuration:
|
||||
https://github.com/mpeltonen/sbt-idea
|
||||
- IDEA Plugin to embed an SBT Console into the IDE:
|
||||
- IDEA Plugin to embed an sbt Console into the IDE:
|
||||
https://github.com/orfjackal/idea-sbt-plugin
|
||||
- Netbeans: https://github.com/remeniuk/sbt-netbeans-plugin
|
||||
- Eclipse: https://github.com/typesafehub/sbteclipse
|
||||
|
|
@ -34,7 +79,7 @@ Web Plugins
|
|||
Test plugins
|
||||
~~~~~~~~~~~~
|
||||
|
||||
- junit\_xml\_listener: https://github.com/ijuma/junit\_xml\_listener
|
||||
- junit_xml_listener: https://github.com/ijuma/junit_xml_listener
|
||||
- sbt-growl-plugin: https://github.com/softprops/sbt-growl-plugin
|
||||
- sbt-teamcity-test-reporting-plugin:
|
||||
https://github.com/guardian/sbt-teamcity-test-reporting-plugin
|
||||
|
|
@ -112,8 +157,7 @@ Code generator plugins
|
|||
- sbt-protobuf (Google Protocol Buffers):
|
||||
https://github.com/gseitz/sbt-protobuf
|
||||
- sbt-avro (Apache Avro): https://github.com/cavorite/sbt-avro
|
||||
- sbt-xjc (XSD binding, using `JAXB
|
||||
XJC <http://download.oracle.com/javase/6/docs/technotes/tools/share/xjc.html>`_):
|
||||
- sbt-xjc (XSD binding, using `JAXB XJC <http://download.oracle.com/javase/6/docs/technotes/tools/share/xjc.html>`_):
|
||||
https://github.com/retronym/sbt-xjc
|
||||
- xsbt-scalate-generate (Generate/Precompile Scalate Templates):
|
||||
https://github.com/backchatio/xsbt-scalate-generate
|
||||
|
|
@ -123,7 +167,7 @@ Code generator plugins
|
|||
version): https://github.com/ritschwumm/xsbt-reflect
|
||||
- sbt-buildinfo (Generate Scala source for any settings):
|
||||
https://github.com/sbt/sbt-buildinfo
|
||||
- lifty (Brings scaffolding to SBT): https://github.com/lifty/lifty
|
||||
- lifty (Brings scaffolding to sbt): https://github.com/lifty/lifty
|
||||
- sbt-thrift (Thrift Code Generation):
|
||||
https://github.com/bigtoast/sbt-thrift
|
||||
- xsbt-hginfo (Generate Scala source code for Mercurial repository
|
||||
|
|
@ -157,7 +201,7 @@ Utility plugins
|
|||
https://github.com/softprops/ls
|
||||
- np (Dead simple new project directory generation):
|
||||
https://github.com/softprops/np
|
||||
- sbt-editsource (A poor man's *sed*\ (1), for SBT):
|
||||
- sbt-editsource (A poor man's *sed*\ (1), for sbt):
|
||||
http://software.clapper.org/sbt-editsource/
|
||||
- sbt-dirty-money (Cleans Ivy2 cache):
|
||||
https://github.com/sbt/sbt-dirty-money
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
=========
|
||||
Community
|
||||
=========
|
||||
|
||||
This part of the wiki has project "meta-information" such as where to
|
||||
find source code and how to contribute. Check out the sidebar on the
|
||||
right for links.
|
||||
|
||||
The mailing list is at
|
||||
http://groups.google.com/group/simple-build-tool/topics. Please use it
|
||||
for questions and comments!
|
||||
|
|
@ -51,7 +51,7 @@ list if you are interested in a specific topic.
|
|||
6. Implement enhanced 0.11-style warn/debug/info/error/trace commands.
|
||||
Currently, you set it like any other setting:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
set logLevel := Level.Warn
|
||||
or
|
||||
|
|
@ -59,7 +59,7 @@ list if you are interested in a specific topic.
|
|||
|
||||
You could make commands that wrap this, like:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
warn test:run
|
||||
|
||||
|
|
@ -73,7 +73,7 @@ replayed or inspected to try to find the cause.
|
|||
Documentation
|
||||
=============
|
||||
|
||||
1. There's a lot to do with this wiki. If you check the wiki out from
|
||||
1. There's a lot to do with this documentation. If you check it out from
|
||||
git, there's a directory called Dormant with some content that needs
|
||||
going through.
|
||||
|
||||
|
|
@ -84,7 +84,7 @@ Documentation
|
|||
3. the :doc:`/Dormant/Configurations` page is missing a list of the built-in
|
||||
configurations and the purpose of each.
|
||||
|
||||
4. grep the wiki's git checkout for "Wiki Maintenance Note" and work on
|
||||
4. grep the documentation's git checkout for "Wiki Maintenance Note" and work on
|
||||
some of those
|
||||
|
||||
5. API docs are much needed.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,21 @@
|
|||
=============================
|
||||
Community Repository Policy
|
||||
=============================
|
||||
|
||||
The community repository has the following guideline for artifacts
|
||||
published to it:
|
||||
|
||||
1. All pubished artifacts are the authors own work or have an
|
||||
appropriate license which grants distribution rights.
|
||||
|
||||
2. All published artifacts come from open source projects, that have an
|
||||
open patch acceptance policy.
|
||||
|
||||
3. All published artifacts are placed under an organization in a DNS
|
||||
domain for which you have the permission to use or are an owner
|
||||
(scala-sbt.org is available for sbt plugins).
|
||||
|
||||
4. All published artifacts are signed by a committer of the project
|
||||
(coming soon).
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,264 @@
|
|||
=======================
|
||||
Deploying to Sonatype
|
||||
=======================
|
||||
|
||||
Deploying to sonatype is easy! Just follow these simple steps:
|
||||
|
||||
First - PGP Signatures
|
||||
----------------------
|
||||
|
||||
You'll need to PGP sign your artifacts for the Sonatype repository.
|
||||
Don't worry, there's a `plugin for
|
||||
that <http://scala-sbt.org/xsbt-gpg-plugin>`_. Follow the instructions
|
||||
for the plugin and you'll have PGP signed artifacts in no time.
|
||||
|
||||
*Note: The plugin is a jvm-only solution to generate PGP keys and sign
|
||||
artifacts. It can work with the GPG command line tool, but the command
|
||||
line is not needed.*
|
||||
|
||||
Second - Maven Publishing Settings
|
||||
----------------------------------
|
||||
|
||||
To publish to a maven repository, you'll need to configure a few
|
||||
settings so that the correct metadata is generated.
|
||||
|
||||
::
|
||||
|
||||
publishMavenStyle := true
|
||||
|
||||
is used to ensure POMs are generated and pushed. Next, you have to set
|
||||
up the repositories you wish to push too. Luckily, Sonatype's OSSRH uses
|
||||
the same URLs for everyone:
|
||||
|
||||
::
|
||||
|
||||
publishTo <<= version { (v: String) =>
|
||||
val nexus = "https://oss.sonatype.org/"
|
||||
if (v.trim.endsWith("SNAPSHOT"))
|
||||
Some("snapshots" at nexus + "content/repositories/snapshots")
|
||||
else
|
||||
Some("releases" at nexus + "service/local/staging/deploy/maven2")
|
||||
}
|
||||
|
||||
Another good idea is to not publish your test artifacts (this is the default):
|
||||
|
||||
::
|
||||
|
||||
publishArtifact in Test := false
|
||||
|
||||
Third - POM Metadata
|
||||
--------------------
|
||||
|
||||
Now, we want to control what's available in the ``pom.xml`` file. This
|
||||
file describes our project in the maven repository and is used by
|
||||
indexing services for search and discover. This means it's important
|
||||
that ``pom.xml`` should have all information we wish to advertise as
|
||||
well as required info!
|
||||
|
||||
First, let's make sure no repositories show up in the POM file. To
|
||||
publish on maven-central, all *required* artifacts must also be hosted
|
||||
on maven central. However, sometimes we have optional dependencies for
|
||||
special features. If that's the case, let's remove the repositories for
|
||||
optional dependencies in our artifact:
|
||||
|
||||
::
|
||||
|
||||
pomIncludeRepository := { _ => false }
|
||||
|
||||
Next, the POM metadata that isn't generated by sbt must be added. This
|
||||
is done through the ``pomExtra`` configuration option:
|
||||
|
||||
::
|
||||
|
||||
pomExtra := (
|
||||
<url>http://jsuereth.com/scala-arm</url>
|
||||
<licenses>
|
||||
<license>
|
||||
<name>BSD-style</name>
|
||||
<url>http://www.opensource.org/licenses/bsd-license.php</url>
|
||||
<distribution>repo</distribution>
|
||||
</license>
|
||||
</licenses>
|
||||
<scm>
|
||||
<url>git@github.com:jsuereth/scala-arm.git</url>
|
||||
<connection>scm:git:git@github.com:jsuereth/scala-arm.git</connection>
|
||||
</scm>
|
||||
<developers>
|
||||
<developer>
|
||||
<id>jsuereth</id>
|
||||
<name>Josh Suereth</name>
|
||||
<url>http://jsuereth.com</url>
|
||||
</developer>
|
||||
</developers>)
|
||||
|
||||
Specifically, the ``url``, ``license``, ``scm.url``, ``scm.connection``
|
||||
and ``developer`` sections are required. The above is an example from
|
||||
the `scala-arm <http://jsuereth.com/scala-arm>`_ project.
|
||||
|
||||
*Note* that sbt will automatically inject ``licenses`` and ``url`` nodes
|
||||
if they are already present in your build file. Thus an alternative to
|
||||
the above ``pomExtra`` is to include the following entries:
|
||||
|
||||
::
|
||||
|
||||
licenses := Seq("BSD-style" -> url("http://www.opensource.org/licenses/bsd-license.php"))
|
||||
|
||||
homepage := Some(url("http://jsuereth.com/scala-arm"))
|
||||
|
||||
This might be advantageous if those keys are used also by other plugins
|
||||
(e.g. ``ls``). You **cannot use both** the sbt ``licenses`` key and the
|
||||
``licenses`` section in ``pomExtra`` at the same time, as this will
|
||||
produce duplicate entries in the final POM file, leading to a rejection
|
||||
in Sonatype's staging process.
|
||||
|
||||
*The full format of a pom.xml file is `outlined
|
||||
here <http://maven.apache.org/pom.html>`_.*
|
||||
|
||||
Fourth - Adding credentials
|
||||
---------------------------
|
||||
|
||||
The credentials for your Sonatype OSSRH account need to be added
|
||||
somewhere. Common convention is a ``~/.sbt/sonatype.sbt`` file with the
|
||||
following:
|
||||
|
||||
::
|
||||
|
||||
credentials += Credentials("Sonatype Nexus Repository Manager",
|
||||
"oss.sonatype.org",
|
||||
"<your username>",
|
||||
"<your password>")
|
||||
|
||||
*Note: The first two strings must be
|
||||
``"Sonatype Nexus Repository Manager"`` and ``"oss.sonatype.org"`` for
|
||||
Ivy to use the credentials.*
|
||||
|
||||
Finally - Publish
|
||||
-----------------
|
||||
|
||||
In sbt, run ``publish`` and you should see something like the following:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> publish
|
||||
Please enter your PGP passphrase> ***********
|
||||
[info] Packaging /home/josh/projects/typesafe/scala-arm/target/scala-2.9.1/scala-arm_2.9.1-1.2.jar ...
|
||||
[info] Wrote /home/josh/projects/typesafe/scala-arm/target/scala-2.9.1/scala-arm_2.9.1-1.2.pom
|
||||
[info] Packaging /home/josh/projects/typesafe/scala-arm/target/scala-2.9.1/scala-arm_2.9.1-1.2-javadoc.jar ...
|
||||
[info] Packaging /home/josh/projects/typesafe/scala-arm/target/scala-2.9.1/scala-arm_2.9.1-1.2-sources.jar ...
|
||||
[info] :: delivering :: com.jsuereth#scala-arm_2.9.1;1.2 :: 1.2 :: release :: Mon Jan 23 13:16:57 EST 2012
|
||||
[info] Done packaging.
|
||||
[info] Done packaging.
|
||||
[info] Done packaging.
|
||||
[info] delivering ivy file to /home/josh/projects/typesafe/scala-arm/target/scala-2.9.1/ivy-1.2.xml
|
||||
[info] published scala-arm_2.9.1 to https://oss.sonatype.org/service/local/staging/deploy/maven2/com/jsuereth/scala-arm_2.9.1/1.2/scala-arm_2.9.1-1.2-sources.jar
|
||||
[info] published scala-arm_2.9.1 to https://oss.sonatype.org/service/local/staging/deploy/maven2/com/jsuereth/scala-arm_2.9.1/1.2/scala-arm_2.9.1-1.2-javadoc.jar.asc
|
||||
[info] published scala-arm_2.9.1 to https://oss.sonatype.org/service/local/staging/deploy/maven2/com/jsuereth/scala-arm_2.9.1/1.2/scala-arm_2.9.1-1.2-sources.jar.asc
|
||||
[info] published scala-arm_2.9.1 to https://oss.sonatype.org/service/local/staging/deploy/maven2/com/jsuereth/scala-arm_2.9.1/1.2/scala-arm_2.9.1-1.2.jar
|
||||
[info] published scala-arm_2.9.1 to https://oss.sonatype.org/service/local/staging/deploy/maven2/com/jsuereth/scala-arm_2.9.1/1.2/scala-arm_2.9.1-1.2.jar.asc
|
||||
[info] published scala-arm_2.9.1 to https://oss.sonatype.org/service/local/staging/deploy/maven2/com/jsuereth/scala-arm_2.9.1/1.2/scala-arm_2.9.1-1.2.pom.asc
|
||||
[info] published scala-arm_2.9.1 to https://oss.sonatype.org/service/local/staging/deploy/maven2/com/jsuereth/scala-arm_2.9.1/1.2/scala-arm_2.9.1-1.2.pom
|
||||
[info] published scala-arm_2.9.1 to https://oss.sonatype.org/service/local/staging/deploy/maven2/com/jsuereth/scala-arm_2.9.1/1.2/scala-arm_2.9.1-1.2-javadoc.jar
|
||||
[success] Total time: 9 s, completed Jan 23, 2012 1:17:03 PM
|
||||
|
||||
After publishing you have to follow the `Release workflow of
|
||||
nexus <https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-8.ReleaseIt>`_.
|
||||
In the future, we hope to provide a Nexus sbt plugin that allows the
|
||||
release workflow procedures to be performed directly from sbt.
|
||||
|
||||
*Note: Staged releases allow testing across large projects of
|
||||
independent releases before pushing the full project.*
|
||||
|
||||
\ *Note:* An error message of
|
||||
``PGPException: checksum mismatch at 0 of 20`` indicates that you got
|
||||
the passphrase wrong. We have found at least on OS X that there may be
|
||||
issues with characters outside the 7-bit ASCII range (e.g. Umlauts). If
|
||||
you are absolutely sure that you typed the right phrase and the error
|
||||
doesn't disappear, try changing the passphrase.
|
||||
|
||||
Summary
|
||||
-------
|
||||
|
||||
To get your project hosted on Sonatype (and Maven Central), you will
|
||||
need to:
|
||||
|
||||
- Have GPG key pair, with published public key,
|
||||
- An sbt file with your Sonatype credentials *that is not pushed to the VCS*,
|
||||
- Modify ``project/plugins.sbt`` to include the ``xsbt-gpg-plugin`` to sign the artefacts,
|
||||
- Modify ``build.sbt`` with the required elements in the generated POM.
|
||||
|
||||
Starting with a project that is not being published, you'll need to
|
||||
install GPG, generate and publish your key. Swtiching to sbt, you'll
|
||||
then need to:
|
||||
|
||||
~/.sbt/sonatype.sbt
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This file (kept *outside the VCS*) contains the Sonatype credentials
|
||||
settings:
|
||||
|
||||
::
|
||||
|
||||
credentials += Credentials("Sonatype Nexus Repository Manager",
|
||||
"oss.sonatype.org",
|
||||
"your-sonatype-username",
|
||||
"your-sonatype-password")
|
||||
|
||||
project/plugins.sbt
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This file specifies the plugins for your project. If you intend to sign
|
||||
the artefacts, you'll need to include @jsuereth's ``xsbt-gpg-plugin``:
|
||||
|
||||
::
|
||||
|
||||
resolvers += Resolver.url("sbt-plugin-releases", /* no new line */
|
||||
new URL("http://scalasbt.artifactoryonline.com/scalasbt/sbt-plugin-releases")) /* no new line */
|
||||
(Resolver.ivyStylePatterns)
|
||||
|
||||
addSbtPlugin("com.jsuereth" % "xsbt-gpg-plugin" % "0.5")
|
||||
|
||||
build.sbt
|
||||
^^^^^^^^^
|
||||
|
||||
Finally, you'll need to tweak the generated POM in your ``build.sbt``.
|
||||
The tweaks include specifying the project's authors, URL, SCM and many
|
||||
others:
|
||||
|
||||
::
|
||||
|
||||
publishTo <<= version { v: String =>
|
||||
val nexus = "https://oss.sonatype.org/"
|
||||
if (v.trim.endsWith("SNAPSHOT"))
|
||||
Some("snapshots" at nexus + "content/repositories/snapshots")
|
||||
else
|
||||
Some("releases" at nexus + "service/local/staging/deploy/maven2")
|
||||
}
|
||||
|
||||
publishMavenStyle := true
|
||||
|
||||
publishArtifact in Test := false
|
||||
|
||||
pomIncludeRepository := { _ => false }
|
||||
|
||||
pomExtra := (
|
||||
<url>http://your.project.url</url>
|
||||
<licenses>
|
||||
<license>
|
||||
<name>BSD-style</name>
|
||||
<url>http://www.opensource.org/licenses/bsd-license.php</url>
|
||||
<distribution>repo</distribution>
|
||||
</license>
|
||||
</licenses>
|
||||
<scm>
|
||||
<url>git@github.com:your-account/your-project.git</url>
|
||||
<connection>scm:git:git@github.com:your-account/your-project.git</connection>
|
||||
</scm>
|
||||
<developers>
|
||||
<developer>
|
||||
<id>you</id>
|
||||
<name>Your Name</name>
|
||||
<url>http://your.url</url>
|
||||
</developer>
|
||||
</developers>
|
||||
)
|
||||
|
||||
|
|
@ -1,10 +1,20 @@
|
|||
.. toctree::
|
||||
:maxdepth: 2
|
||||
=========
|
||||
Community
|
||||
=========
|
||||
|
||||
Changes
|
||||
ChangeSummary_0.12.0
|
||||
Community
|
||||
Credits
|
||||
Nightly-Builds
|
||||
Opportunities
|
||||
sbt-0.10-plugins-list
|
||||
This part of the documentation has project "meta-information" such as where to
|
||||
find source code and how to contribute.
|
||||
|
||||
The mailing list is at
|
||||
http://groups.google.com/group/simple-build-tool/topics. Please use it
|
||||
for questions and comments!
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
Credits
|
||||
Community-Plugins
|
||||
Using-Sonatype
|
||||
Nightly-Builds
|
||||
Changes
|
||||
Opportunities
|
||||
|
|
|
|||
|
|
@ -197,8 +197,8 @@ page) are actually convenience methods that translate to ``artifacts``:
|
|||
|
||||
That is, the following two dependency declarations are equivalent:
|
||||
|
||||
\`\`\`scala libraryDependencies += "org.testng" % "testng" % "5.7"
|
||||
classifier "jdk15"
|
||||
::
|
||||
|
||||
libraryDependencies += "org.testng" % "testng" % "5.7" artifacts(
|
||||
Artifact("testng", "jdk15") ) \`\`\`
|
||||
libraryDependencies += "org.testng" % "testng" % "5.7" classifier "jdk15"
|
||||
|
||||
libraryDependencies += "org.testng" % "testng" % "5.7" artifacts(Artifact("testng", "jdk15") )
|
||||
|
|
|
|||
|
|
@ -162,4 +162,6 @@ in classpath.
|
|||
|
||||
Or shorter:
|
||||
|
||||
``scala unmanagedClasspath in Runtime <+= (baseDirectory) map { bd => Attributed.blank(bd / "config") }``
|
||||
::
|
||||
|
||||
unmanagedClasspath in Runtime <+= (baseDirectory) map { bd => Attributed.blank(bd / "config") }
|
||||
|
|
|
|||
|
|
@ -55,10 +55,12 @@ Version-specific Compiler Plugin Example
|
|||
|
||||
Adding a version-specific compiler plugin can be done as follows:
|
||||
|
||||
\`\`\`scala autoCompilerPlugins := true
|
||||
::
|
||||
|
||||
libraryDependencies <<= (scalaVersion, libraryDependencies) { (ver,
|
||||
deps) => deps :+ compilerPlugin("org.scala-lang.plugins" %
|
||||
"continuations" % ver) }
|
||||
autoCompilerPlugins := true
|
||||
|
||||
scalacOptions += "-P:continuations:enable" \`\`\`
|
||||
libraryDependencies <<= (scalaVersion, libraryDependencies) { (ver, deps) =>
|
||||
deps :+ compilerPlugin("org.scala-lang.plugins" % "continuations" % ver)
|
||||
}
|
||||
|
||||
scalacOptions += "-P:continuations:enable"
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ started up with these commands already executed:
|
|||
For example, running external processes with sbt's process library (to
|
||||
be included in the standard library in Scala 2.9):
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> "tar -zcvf project-src.tar.gz src" !
|
||||
> "find project -name *.jar" !
|
||||
|
|
@ -44,26 +44,26 @@ Accessing settings
|
|||
|
||||
To get a particular setting, use the form:
|
||||
|
||||
::
|
||||
.. code-block:: scala
|
||||
|
||||
> val value = get(<key> in <scope>)
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
::
|
||||
.. code-block:: scala
|
||||
|
||||
> IO.delete( get(classesDirectory in Compile) )
|
||||
|
||||
Show current compile options:
|
||||
|
||||
::
|
||||
.. code-block:: scala
|
||||
|
||||
> get(scalacOptions in Compile) foreach println
|
||||
|
||||
Show additionally configured repositories.
|
||||
|
||||
::
|
||||
.. code-block:: scala
|
||||
|
||||
> get( resolvers ) foreach println
|
||||
|
||||
|
|
@ -72,7 +72,7 @@ Evaluating tasks
|
|||
|
||||
To evaluate a task, use the form:
|
||||
|
||||
::
|
||||
.. code-block:: scala
|
||||
|
||||
> val value = evalTask(<key> in <scope>, currentState)
|
||||
|
||||
|
|
@ -81,13 +81,13 @@ Examples
|
|||
|
||||
Show all repositories, including defaults.
|
||||
|
||||
::
|
||||
.. code-block:: scala
|
||||
|
||||
> evalTask( fullResolvers, currentState ) foreach println
|
||||
|
||||
Show the classpaths used for compilation and testing:
|
||||
|
||||
::
|
||||
.. code-block:: scala
|
||||
|
||||
> evalTask( fullClasspath in Compile, currentState ).files foreach println
|
||||
> evalTask( fullClasspath in Test, currentState ).files foreach println
|
||||
|
|
@ -96,10 +96,12 @@ Show the remaining commands to be executed in the build (more
|
|||
interesting if you invoke ``console-project`` like
|
||||
``; console-project ; clean ; compile``):
|
||||
|
||||
::
|
||||
.. code-block:: scala
|
||||
|
||||
> remainingCommands
|
||||
|
||||
Show the number of currently registered commands:
|
||||
|
||||
``scala > definedCommands.size``
|
||||
.. code-block:: scala
|
||||
|
||||
> definedCommands.size
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ version (no ``+`` prefix) and then cross-build (using ``+``)
|
|||
occasionally and when releasing. The ultimate purpose of ``+`` is to
|
||||
cross-publish your project. That is, by doing:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> + publish
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,121 @@
|
|||
===========================
|
||||
Dependency Management Flow
|
||||
===========================
|
||||
|
||||
0.12.1 addresses several issues with dependency management. These fixes
|
||||
were made possible by specific, reproducible examples, such as a
|
||||
situation where the resolution cache got out of date (gh-532). A brief summary of
|
||||
the current work flow with dependency management in sbt follows.
|
||||
|
||||
Background
|
||||
==========
|
||||
|
||||
``update`` resolves dependencies according to the settings in a build
|
||||
file, such as ``libraryDependencies`` and ``resolvers``. Other tasks use
|
||||
the output of ``update`` (an ``UpdateReport``) to form various
|
||||
classpaths. Tasks that in turn use these classpaths, such as ``compile``
|
||||
or ``run``, thus indirectly depend on ``update``. This means that before
|
||||
``compile`` can run, the ``update`` task needs to run. However,
|
||||
resolving dependencies on every ``compile`` would be unnecessarily slow
|
||||
and so ``update`` must be particular about when it actually performs a
|
||||
resolution.
|
||||
|
||||
Caching and Configuration
|
||||
=========================
|
||||
|
||||
1. Normally, if no dependency management configuration has changed since
|
||||
the last successful resolution and the retrieved files are still
|
||||
present, sbt does not ask Ivy to perform resolution.
|
||||
2. Changing the configuration, such as adding or removing dependencies
|
||||
or changing the version or other attributes of a dependency, will
|
||||
automatically cause resolution to be performed. Updates to locally
|
||||
published dependencies should be detected in sbt 0.12.1 and later and
|
||||
will force an ``update``. Dependent tasks like ``compile`` and
|
||||
``run`` will get updated classpaths.
|
||||
3. Directly running the ``update`` task (as opposed to a task that
|
||||
depends on it) will force resolution to run, whether or not
|
||||
configuration changed. This should be done in order to refresh remote
|
||||
SNAPSHOT dependencies.
|
||||
4. When ``offline := true``, remote SNAPSHOTs will not be updated by a
|
||||
resolution, even an explicitly requested ``update``. This should
|
||||
effectively support working without a connection to remote
|
||||
repositories. Reproducible examples demonstrating otherwise are
|
||||
appreciated. Obviously, ``update`` must have successfully run before
|
||||
going offline.
|
||||
5. Overriding all of the above, ``skip in update := true`` will tell sbt
|
||||
to never perform resolution. Note that this can cause dependent tasks
|
||||
to fail. For example, compilation may fail if jars have been deleted
|
||||
from the cache (and so needed classes are missing) or a dependency
|
||||
has been added (but will not be resolved because skip is true). Also,
|
||||
``update`` itself will immediately fail if resolution has not been
|
||||
allowed to run since the last ``clean``.
|
||||
|
||||
General troubleshooting steps
|
||||
=============================
|
||||
|
||||
A. Run ``update`` explicitly. This will typically fix problems with out
|
||||
of date SNAPSHOTs or locally published artifacts.
|
||||
|
||||
B. If a file cannot be
|
||||
found, look at the output of ``update`` to see where Ivy is looking for
|
||||
the file. This may help diagnose an incorrectly defined dependency or a
|
||||
dependency that is actually not present in a repository.
|
||||
|
||||
C. ``last update`` contains more information about the most recent
|
||||
resolution and download. The amount of debugging output from Ivy is
|
||||
high, so you may want to use ``last-grep`` (run ``help last-grep`` for
|
||||
usage).
|
||||
|
||||
D. Run ``clean`` and then ``update``. If this works, it could
|
||||
indicate a bug in sbt, but the problem would need to be reproduced in
|
||||
order to diagnose and fix it.
|
||||
|
||||
E. Before deleting all of the Ivy cache,
|
||||
first try deleting files in ``~/.ivy2/cache`` related to problematic
|
||||
dependencies. For example, if there are problems with dependency
|
||||
``"org.example" % "demo" % "1.0"``, delete
|
||||
``~/.ivy2/cache/org.example/demo/1.0/`` and retry ``update``. This
|
||||
avoids needing to redownload all dependencies.
|
||||
|
||||
F. Normal sbt usage
|
||||
should not require deleting files from ``~/.ivy2/cache``, especially if
|
||||
the first four steps have been followed. If deleting the cache fixes a
|
||||
dependency management issue, please try to reproduce the issue and
|
||||
submit a test case.
|
||||
|
||||
Plugins
|
||||
=======
|
||||
|
||||
These troubleshooting steps can be run for plugins by changing to the
|
||||
build definition project, running the commands, and then returning to
|
||||
the main project. For example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> reload plugins
|
||||
> update
|
||||
> reload return
|
||||
|
||||
Notes
|
||||
=====
|
||||
|
||||
A. Configure offline behavior for all projects on a machine by putting
|
||||
``offline := true`` in ``~/.sbt/global.sbt``. A command that does this
|
||||
for the user would make a nice pull request. Perhaps the setting of
|
||||
offline should go into the output of ``about`` or should it be a warning
|
||||
in the output of ``update`` or both?
|
||||
|
||||
B. The cache improvements in 0.12.1 address issues in the change detection
|
||||
for ``update`` so that it will correctly re-resolve automatically in more
|
||||
situations. A problem with an out of date cache can usually be attributed
|
||||
to a bug in that change detection if explicitly running ``update`` fixes
|
||||
the problem.
|
||||
|
||||
C. A common solution to dependency management problems in sbt has been to
|
||||
remove ``~/.ivy2/cache``. Before doing this with 0.12.1, be sure to
|
||||
follow the steps in the troubleshooting section first. In particular,
|
||||
verify that a ``clean`` and an explicit ``update`` do not solve the
|
||||
issue.
|
||||
|
||||
D. There is no need to mark SNAPSHOT dependencies as ``changing()``
|
||||
because sbt configures Ivy to know this already.
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
====================
|
||||
Detailed Topic Pages
|
||||
====================
|
||||
|
||||
This part of the wiki has pages documenting particular sbt topics.
|
||||
|
||||
Before reading anything in here, you will need the information in the
|
||||
:doc:`Getting Started Guide </Getting-Started/Welcome>` as a foundation.
|
||||
|
||||
Other resources include the :doc:`Examples </Examples/Examples>` and
|
||||
:doc:`extending sbt </Extending/Extending>` areas on the wiki, and the
|
||||
`API Documentation <../../api/index.html>`_
|
||||
|
||||
See the sidebar on the right for an index of topics.
|
||||
|
|
@ -14,7 +14,7 @@ Selecting commands, tasks, and settings
|
|||
|
||||
A fully-qualified reference to a setting or task looks like:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
{<build-uri>}<project-id>/config:inkey::key
|
||||
|
||||
|
|
@ -42,7 +42,7 @@ selected, where order is determined by the project definition's
|
|||
For example, the following are equivalent when run in a project ``root``
|
||||
in the build in ``/home/user/sample/``:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> compile
|
||||
> compile:compile
|
||||
|
|
@ -57,7 +57,7 @@ for the ``test`` configuration, the configuration axis must be specified
|
|||
like ``test:run``. Some other examples that require the explicit
|
||||
``test:`` axis:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> test:console-quick
|
||||
> test:console
|
||||
|
|
@ -78,7 +78,7 @@ This is done with the task axis, which selects the task to apply a
|
|||
setting to. For example, the following prints the output jar for the
|
||||
different package tasks.
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> package::artifact-path
|
||||
[info] /home/user/sample/target/scala-2.8.1.final/demo_2.8.1-0.1.jar
|
||||
|
|
@ -111,7 +111,7 @@ task or the value and type of a setting. The following section of output
|
|||
is labeled "Provided by". This shows the actual scope where the setting
|
||||
is defined. For example,
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> inspect library-dependencies
|
||||
[info] Setting: scala.collection.Seq[sbt.ModuleID] = List(org.scalaz:scalaz-core:6.0-SNAPSHOT, org.scala-tools.testing:scalacheck:1.8:test)
|
||||
|
|
@ -123,7 +123,7 @@ This shows that ``library-dependencies`` has been defined on the current
|
|||
project (``{file:/home/user/sample/}root``) in the global configuration
|
||||
(``*:``). For a task like ``update``, the output looks like:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> inspect update
|
||||
[info] Task: sbt.UpdateReport
|
||||
|
|
@ -137,7 +137,7 @@ Related Settings
|
|||
The "Related" section of ``inspect`` output lists all of the definitions
|
||||
of a key. For example,
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> inspect compile
|
||||
...
|
||||
|
|
@ -163,7 +163,7 @@ Requested Dependencies
|
|||
|
||||
As an example, we'll look at ``console``:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> inspect console
|
||||
...
|
||||
|
|
@ -191,7 +191,7 @@ tasks like ``compile`` and ``test``. For example, we can infer from the
|
|||
previous example how to add code to be run when the Scala interpreter
|
||||
starts up:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> set initialCommands in Compile in console := "import mypackage._"
|
||||
> console
|
||||
|
|
@ -219,7 +219,7 @@ exactly which scope is providing a value for a setting. Combining
|
|||
scopes that will affect a setting. Returning to the example in Requested
|
||||
Dependencies,
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> inspect actual console
|
||||
...
|
||||
|
|
@ -238,7 +238,7 @@ For ``initial-commands``, we see that it comes from the global scope
|
|||
(``*/*:``). Combining this with the relevant output from
|
||||
``inspect console``:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
compile:console::initial-commands
|
||||
|
||||
|
|
@ -247,7 +247,7 @@ scope, as specific as the current project's ``console`` task scope, or
|
|||
anything in between. This means that we can, for example, set
|
||||
``initial-commands`` for the whole project and will affect ``console``:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> set initialCommands := "import mypackage._"
|
||||
...
|
||||
|
|
@ -256,7 +256,7 @@ The reason we might want to set it here this is that other console tasks
|
|||
will use this value now. We can see which ones use our new setting by
|
||||
looking at the reverse dependencies output of ``inspect actual``:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> inspect actual initial-commands
|
||||
...
|
||||
|
|
@ -277,7 +277,7 @@ specific task axis:
|
|||
``console > set initialCommands in console := "import mypackage._" > set initialCommands in consoleQuick := "import mypackage._"``
|
||||
or configuration axis:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> set initialCommands in Compile := "import mypackage._"
|
||||
> set initialCommands in Test := "import mypackage._"
|
||||
|
|
@ -297,7 +297,7 @@ requested key.
|
|||
|
||||
As an example, consider the initial commands for ``console`` again:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> inspect console::initial-commands
|
||||
...
|
||||
|
|
|
|||
|
|
@ -73,55 +73,56 @@ by the following grammar. ``'nl'`` is a newline or end of file and
|
|||
``'text'`` is plain text without newlines or the surrounding delimiters
|
||||
(such as parentheses or square brackets):
|
||||
|
||||
::
|
||||
|
||||
configuration ::= scala app repositories boot log app-properties
|
||||
scala ::= '[' 'scala' ']' nl version nl classifiers nl
|
||||
app ::= '[' 'app' ']' nl org nl name nl version nl components nl class nl cross-versioned nl resources nl classifiers nl
|
||||
repositories ::= '[' 'repositories' ']' nl (repository nl)*
|
||||
boot ::= '[' 'boot' ']' nl directory nl bootProperties nl search nl promptCreate nl promptFill nl quickOption nl
|
||||
log ::= '[' 'log' ']' nl logLevel nl
|
||||
app-properties ::= '[' 'app-properties' ']' nl (property nl)*
|
||||
ivy ::= '[' 'ivy' ']' nl homeDirectory nl checksums nl overrideRepos nl repoConfig nl
|
||||
|
||||
directory ::= 'directory' ':' path
|
||||
bootProperties ::= 'properties' ':' path
|
||||
search ::= 'search' ':' ('none'|'nearest'|'root-first'|'only') (',' path)*
|
||||
logLevel ::= 'log-level' ':' ('debug' | 'info' | 'warn' | 'error')
|
||||
promptCreate ::= 'prompt-create' ':' label
|
||||
promptFill ::= 'prompt-fill' ':' boolean
|
||||
quickOption ::= 'quick-option' ':' boolean
|
||||
|
||||
version ::= 'version' ':' versionSpecification
|
||||
versionSpecification ::= readProperty | fixedVersion
|
||||
readProperty ::= 'read' '(' propertyName ')' '[' default ']'
|
||||
fixedVersion ::= text
|
||||
|
||||
classifiers ::= 'classifiers' ':' text (',' text)*
|
||||
homeDirectory ::= 'ivy-home' ':' path
|
||||
checksums ::= 'checksums' ':' checksum (',' checksum)*
|
||||
overrideRepos ::= 'override-build-repos' ':' boolean
|
||||
repoConfig ::= 'repository-config' ':' path
|
||||
|
||||
org ::= 'org' ':' text
|
||||
name ::= 'name' ':' text
|
||||
class ::= 'class' ':' text
|
||||
components ::= 'components' ':' component (',' component)*
|
||||
cross-versioned ::= 'cross-versioned' ':' boolean
|
||||
resources ::= 'resources' ':' path (',' path)*
|
||||
|
||||
repository ::= ( predefinedRepository | customRepository ) nl
|
||||
predefinedRepository ::= 'local' | 'maven-local' | 'maven-central'
|
||||
customRepository ::= label ':' url [ [',' ivy-pattern] ',' artifact-pattern]
|
||||
|
||||
property ::= label ':' propertyDefinition (',' propertyDefinition)*
|
||||
propertyDefinition ::= mode '=' (set | prompt)
|
||||
mode ::= 'quick' | 'new' | 'fill'
|
||||
set ::= 'set' '(' value ')'
|
||||
prompt ::= 'prompt' '(' label ')' ('[' default ']')?
|
||||
|
||||
boolean ::= 'true' | 'false'
|
||||
path, propertyName, label, default, checksum ::= text
|
||||
.. productionlist::
|
||||
configuration: `scala` `app` `repositories` `boot` `log` `appProperties`
|
||||
scala: "[" "scala" "]" `nl` `version` `nl` `classifiers` `nl`
|
||||
app: "[" "app" "]" `nl` `org` `nl` `name` `nl` `version` `nl` `components` `nl` `class` `nl` `crossVersioned` `nl` `resources` `nl` `classifiers` `nl`
|
||||
repositories: "[" "repositories" "]" `nl` (`repository` `nl`)*
|
||||
boot: "[" "boot" "]" `nl` `directory` `nl` `bootProperties` `nl` `search` `nl` `promptCreate` `nl` `promptFill` `nl` `quickOption` `nl`
|
||||
log: "["' "log" "]" `nl` `logLevel` `nl`
|
||||
appProperties: "[" "app-properties" "]" nl (property nl)*
|
||||
ivy: "[" "ivy" "]" `nl` `homeDirectory` `nl` `checksums` `nl` `overrideRepos` `nl` `repoConfig` `nl`
|
||||
directory: "directory" ":" `path`
|
||||
bootProperties: "properties" ":" `path`
|
||||
search: "search" ":" ("none" | "nearest" | "root-first" | "only" ) ("," `path`)*
|
||||
logLevel: "log-level" ":" ("debug" | "info" | "warn" | "error")
|
||||
promptCreate: "prompt-create" ":" `label`
|
||||
promptFill: "prompt-fill" ":" `boolean`
|
||||
quickOption: "quick-option" ":" `boolean`
|
||||
version: "version" ":" `versionSpecification`
|
||||
versionSpecification: `readProperty` | `fixedVersion`
|
||||
readProperty: "read" "(" `propertyName` ")" "[" `default` "]"
|
||||
fixedVersion: text
|
||||
classifiers: "classifiers" ":" text ("," text)*
|
||||
homeDirectory: "ivy-home" ":" `path`
|
||||
checksums: "checksums" ":" `checksum` ("," `checksum`)*
|
||||
overrideRepos: "override-uild-repos" ":" `boolean`
|
||||
repoConfig: "repository-config" ":" `path`
|
||||
org: "org" ":" text
|
||||
name: "name" ":" text
|
||||
class: "class" ":" text
|
||||
components: "components" ":" `component` ("," `component`)*
|
||||
crossVersioned: "cross-versioned" ":" `boolean`
|
||||
resources: "resources" ":" `path` ("," `path`)*
|
||||
repository: ( `predefinedRepository` | `customRepository` ) `nl`
|
||||
predefinedRepository: "local" | "maven-local" | "maven-central"
|
||||
customRepository: `label` ":" `url` [ ["," `ivyPattern`] "," `artifactPattern`]
|
||||
property: `label` ":" `propertyDefinition` ("," `propertyDefinition`)*
|
||||
propertyDefinition: `mode` "=" (`set` | `prompt`)
|
||||
mode: "quick" | "new" | "fill"
|
||||
set: "set" "(" value ")"
|
||||
prompt: "prompt" "(" `label` ")" ("[" `default` "]")?
|
||||
boolean: "true" | "false"
|
||||
nl: "\r\n" | "\n" | "\r"
|
||||
path: text
|
||||
propertyName: text
|
||||
label: text
|
||||
default: text
|
||||
checksum: text
|
||||
ivyPattern: text
|
||||
artifactPattern: text
|
||||
url: text
|
||||
component: text
|
||||
|
||||
In addition to the grammar specified here, property values may include
|
||||
variable substitutions. A variable substitution has one of these forms:
|
||||
|
|
@ -141,7 +142,7 @@ Example
|
|||
|
||||
The default configuration file for sbt looks like:
|
||||
|
||||
::
|
||||
.. code-block:: ini
|
||||
|
||||
[scala]
|
||||
version: ${sbt.scala.version-auto}
|
||||
|
|
@ -196,7 +197,7 @@ default, this is an absolute path that is shared by all launched
|
|||
instances on the machine. If multiple versions access it simultaneously.
|
||||
, you might see messages like:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
Waiting for lock on <lock-file> to be available...
|
||||
|
||||
|
|
@ -258,7 +259,7 @@ obtain the necessary jars to launch the application. The
|
|||
to. Locking is done on the directory, so it can be shared system-wide.
|
||||
The launcher retrieves the requested version of Scala to
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
${boot.directory}/${scala.version}/lib/
|
||||
|
||||
|
|
@ -268,7 +269,7 @@ downloaded. If the directory does not exist, the launcher uses Apache
|
|||
Ivy to resolve and retrieve the jars. A similar process occurs for the
|
||||
application itself. It and its dependencies are retrieved to
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
${boot.directory}/${scala.version}/${app.org}/${app.name}/.
|
||||
|
||||
|
|
@ -346,7 +347,7 @@ that uses some of the information:
|
|||
Next, define a configuration file for the launcher. For the above class,
|
||||
it might look like:
|
||||
|
||||
::
|
||||
.. code-block:: ini
|
||||
|
||||
[scala]
|
||||
version: 2.9.2
|
||||
|
|
@ -374,14 +375,12 @@ The second two require providing a configuration file for download.
|
|||
|
||||
- Replace the /sbt/sbt.boot.properties file in the launcher jar and
|
||||
distribute the modified jar. The user would need a script to run
|
||||
'java -jar your-launcher.jar arg1 arg2 ...'.
|
||||
``java -jar your-launcher.jar arg1 arg2 ...``.
|
||||
- The user downloads the launcher jar and you provide the configuration
|
||||
file.
|
||||
|
||||
- The user needs to run 'java
|
||||
-Dsbt.boot.properties=your.boot.properties -jar launcher.jar'.
|
||||
- The user needs to run ``java -Dsbt.boot.properties=your.boot.properties -jar launcher.jar``.
|
||||
- The user already has a script to run the launcher (call it
|
||||
'launch'). The user needs to run
|
||||
``launch @your.boot.properties your-arg-1 your-arg-2``
|
||||
'launch'). The user needs to run ``launch @your.boot.properties your-arg-1 your-arg-2``
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -199,7 +199,7 @@ The repositories used by the launcher can be overridden by defining
|
|||
with the same format as the :doc:`Launcher` configuration file. For
|
||||
example:
|
||||
|
||||
::
|
||||
.. code-block:: ini
|
||||
|
||||
[repositories]
|
||||
local
|
||||
|
|
@ -366,7 +366,7 @@ both the sbt launcher and by projects, by setting the system property
|
|||
|
||||
For example:
|
||||
|
||||
::
|
||||
.. code-block:: text
|
||||
|
||||
java -Dsbt.ivy.home=/tmp/.ivy2/ ...
|
||||
|
||||
|
|
|
|||
|
|
@ -114,11 +114,12 @@ which is implicitly added to a function of type ``A => Option[B]``. For
|
|||
example, to try to relativize a file against some base directories but
|
||||
fall back to flattening:
|
||||
|
||||
\`\`\`scala import Path.relativeTo val files: Seq[File] =
|
||||
file("/a/b/C.scala") :: file("/zzz/D.scala") :: Nil val baseDirectories:
|
||||
Seq[File] = file("/a") :: Nil val mappings: Seq[(File,String)] = files x
|
||||
( relativeTo(baseDirectories) \| flat )
|
||||
::
|
||||
|
||||
val expected = (file("/a/b/C.scala") -> "b/C.scala") ) ::
|
||||
(file("/zzz/D.scala") -> "D.scala") ) :: Nil assert( mappings ==
|
||||
expected ) \`\`\`
|
||||
import Path.relativeTo
|
||||
val files: Seq[File] = file("/a/b/C.scala") :: file("/zzz/D.scala") :: Nil
|
||||
val baseDirectories: Seq[File] = file("/a") :: Nil
|
||||
val mappings: Seq[(File,String)] = files x ( relativeTo(baseDirectories) | flat )
|
||||
|
||||
val expected = (file("/a/b/C.scala") -> "b/C.scala") ) :: (file("/zzz/D.scala") -> "D.scala") ) :: Nil
|
||||
assert( mappings == expected )
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ Download sbt |version| as described on :doc:`the setup page </Getting-Started/Se
|
|||
|
||||
You can run |version| the same way that you run 0.7.x, either simply:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
java -jar sbt-launch.jar
|
||||
|
||||
|
|
@ -75,7 +75,7 @@ looks like a property file, yet contains Scala code in a special format.
|
|||
|
||||
A ``build.properties`` file like:
|
||||
|
||||
::
|
||||
.. code-block:: text
|
||||
|
||||
#Project properties
|
||||
#Fri Jan 07 15:34:00 GMT 2011
|
||||
|
|
@ -102,7 +102,7 @@ Now becomes part of your ``build.sbt`` file with lines like:
|
|||
Currently, a ``project/build.properties`` is still needed to explicitly
|
||||
select the sbt version. For example:
|
||||
|
||||
::
|
||||
.. code-block:: text
|
||||
|
||||
sbt.version=|release|
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,9 @@ Error handling and tab completion make this picture more complicated,
|
|||
but we'll stick with Option for this discussion.
|
||||
|
||||
The following examples assume the imports:
|
||||
``scala import sbt._ import complete.DefaultParsers._``
|
||||
|
||||
import sbt._
|
||||
import complete.DefaultParsers._
|
||||
|
||||
Basic parsers
|
||||
-------------
|
||||
|
|
|
|||
|
|
@ -123,6 +123,9 @@ Search for uses of ``null`` in the source directory:
|
|||
|
||||
"find src -name *.scala -exec grep null {} ;" #| "xargs test -z" #&& "echo null-free" #|| "echo null detected" !
|
||||
|
||||
Use ``cat``:
|
||||
Use ``cat``::
|
||||
|
||||
``scala val spde = url("http://technically.us/spde/About") val dispatch = url("http://databinder.net/dispatch/About") val build = file("project/build.properties") cat(spde, dispatch, build) #| "grep -i scala" !``
|
||||
val spde = url("http://technically.us/spde/About")
|
||||
val dispatch = url("http://databinder.net/dispatch/About")
|
||||
val build = file("project/build.properties")
|
||||
cat(spde, dispatch, build) #| "grep -i scala" !
|
||||
|
|
|
|||
|
|
@ -75,7 +75,7 @@ The second and better way is to load them from a file, for example:
|
|||
The credentials file is a properties file with keys ``realm``, ``host``,
|
||||
``user``, and ``password``. For example:
|
||||
|
||||
::
|
||||
.. code-block:: text
|
||||
|
||||
realm=Sonatype Nexus Repository Manager
|
||||
host=nexus.scala-tools.org
|
||||
|
|
|
|||
|
|
@ -93,7 +93,7 @@ atomic.
|
|||
URL
|
||||
^^^
|
||||
|
||||
Define a URL repository at .\ ``"http://example.org/repo-releases/"``.
|
||||
Define a URL repository at ``"http://example.org/repo-releases/"``.
|
||||
|
||||
::
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Setup with Conscript
|
|||
|
||||
Install `conscript <https://github.com/n8han/conscript>`_.
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
cs harrah/xsbt --branch 0.12.0
|
||||
|
||||
|
|
@ -43,14 +43,14 @@ whatever names you like).
|
|||
the main class, by adding the ``-Dsbt.main.class=sbt.ScriptMain``
|
||||
parameter to the ``java`` command. Its command line should look like:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
java -Dsbt.main.class=sbt.ScriptMain -Dsbt.boot.directory=/home/user/.sbt/boot -jar sbt-launch.jar "$@"
|
||||
|
||||
For the REPL runner ``screpl``, use ``sbt.ConsoleMain`` as the main
|
||||
class:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
java -Dsbt.main.class=sbt.ConsoleMain -Dsbt.boot.directory=/home/user/.sbt/boot -jar sbt-launch.jar "$@"
|
||||
|
||||
|
|
@ -78,7 +78,7 @@ run, the example should retrieve Scala, the required dependencies,
|
|||
compile the script, and run it directly. For example, if you name it
|
||||
``dispatch_example.scala``, you would do on Unix:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
chmod u+x dispatch_example.scala
|
||||
./dispatch_example.scala
|
||||
|
|
@ -143,7 +143,7 @@ Example:
|
|||
To add the Sonatype snapshots repository and add Scalaz 7.0-SNAPSHOT to
|
||||
REPL classpath:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
screpl "sonatype-releases at https://oss.sonatype.org/content/repositories/snapshots/" "org.scalaz%%scalaz-core%7.0-SNAPSHOT"
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ default encoding for your platform. In this case, you will need to add
|
|||
the option ``-Dfile.encoding=<encoding>`` in your ``sbt`` script to set
|
||||
the encoding, which might look like:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
java -Dfile.encoding=UTF8
|
||||
|
||||
|
|
@ -30,8 +30,12 @@ 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
|
||||
application. For example a common set of memory-related options is:
|
||||
|
||||
``text java -Xmx1536M -Xss1M -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=256m``
|
||||
## Boot directory
|
||||
.. code-block:: console
|
||||
|
||||
java -Xmx1536M -Xss1M -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=256m``
|
||||
|
||||
Boot directory
|
||||
--------------
|
||||
|
||||
``sbt-launch.jar`` is just a bootstrap; the actual meat of sbt, and the
|
||||
Scala compiler and standard library, are downloaded to the shared
|
||||
|
|
@ -44,7 +48,7 @@ to avoid sharing the boot directory between projects. For example, the
|
|||
following uses the pre-0.11 style of putting the boot directory in
|
||||
``project/boot/``:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
java -Dsbt.boot.directory=project/boot/
|
||||
|
||||
|
|
@ -56,14 +60,14 @@ On Unix, sbt will pick up any HTTP proxy settings from the
|
|||
authentication, your ``sbt`` script must also pass flags to set the
|
||||
``http.proxyUser`` and ``http.proxyPassword`` properties:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
java -Dhttp.proxyUser=username -Dhttp.proxyPassword=mypassword
|
||||
|
||||
On Windows, your script should set properties for proxy host, port, and
|
||||
if applicable, username and password:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
java -Dhttp.proxyHost=myproxy -Dhttp.proxyPort=8080 -Dhttp.proxyUser=username -Dhttp.proxyPassword=mypassword
|
||||
|
||||
|
|
|
|||
|
|
@ -144,17 +144,23 @@ Tasks without inputs
|
|||
|
||||
A task that takes no arguments can be defined using ``:=``
|
||||
|
||||
\`\`\`scala
|
||||
::
|
||||
|
||||
intTask := 1 + 2
|
||||
intTask := 1 + 2
|
||||
|
||||
stringTask := System.getProperty("user.name")
|
||||
stringTask := System.getProperty("user.name")
|
||||
|
||||
sampleTask := { val sum = 1 + 2 println("sum: " + sum) sum }
|
||||
\`\`\ ``As mentioned in the introduction, a task is evaluated on demand. Each time``\ sample-task\ ``is invoked, for example, it will print the sum. If the username changes between runs,``\ string-task\`
|
||||
will take different values in those separate runs. (Within a run, each
|
||||
task is evaluated at most once.) In contrast, settings are evaluated
|
||||
once on project load and are fixed until the next reload.
|
||||
sampleTask := {
|
||||
val sum = 1 + 2
|
||||
println("sum: " + sum)
|
||||
sum
|
||||
}
|
||||
|
||||
As mentioned in the introduction, a task is evaluated on demand.
|
||||
Each time ``sample-task`` is invoked, for example, it will print the sum.
|
||||
If the username changes between runs, ``string-task`` will take different values in those separate runs.
|
||||
(Within a run, each task is evaluated at most once.)
|
||||
In contrast, settings are evaluated once on project load and are fixed until the next reload.
|
||||
|
||||
Tasks with inputs
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -246,7 +252,12 @@ The examples in this section use the following key definitions, which
|
|||
would go in a ``Build`` object in a :doc:`Full Configuration </Getting-Started/Full-Def>`.
|
||||
Alternatively, the keys may be specified inline, as discussed above.
|
||||
|
||||
``scala val unitTask = TaskKey[Unit]("unit-task") val intTask = TaskKey[Int]("int-task") val stringTask = TaskKey[String]("string-task")``
|
||||
::
|
||||
|
||||
val unitTask = TaskKey[Unit]("unit-task")
|
||||
val intTask = TaskKey[Int]("int-task")
|
||||
val stringTask = TaskKey[String]("string-task")
|
||||
|
||||
The examples themselves are valid settings in a ``build.sbt`` file or as
|
||||
part of a sequence provided to ``Project.settings``.
|
||||
|
||||
|
|
@ -360,7 +371,7 @@ You can scope logging settings by the specific task's scope:
|
|||
|
||||
To obtain the last logging output from a task, use the ``last`` command:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
$ last my-task
|
||||
[debug] Saying hi...
|
||||
|
|
@ -436,365 +447,46 @@ evaluates the provided function if it fails.
|
|||
|
||||
For example:
|
||||
|
||||
\`\`\`scala intTask := error("Failed.")
|
||||
::
|
||||
|
||||
intTask <<= intTask mapFailure { (inc: Incomplete) => println("Ignoring
|
||||
failure: " + inc) 3 }
|
||||
\`\`\ ``This overrides the``\ int-task\ ``so that the original exception is printed and the constant``\ 3\`
|
||||
is returned.
|
||||
intTask := error("Failed.")
|
||||
|
||||
intTask <<= intTask mapFailure { (inc: Incomplete) =>
|
||||
println("Ignoring failure: " + inc)
|
||||
3
|
||||
}
|
||||
|
||||
This overrides the ``int-task`` so that the original exception is printed and the constant ``3`` is returned.
|
||||
|
||||
``mapFailure`` does not prevent other tasks that depend on the target
|
||||
from failing. Consider the following example:
|
||||
|
||||
\`\`\`scala intTask := if(shouldSucceed) 5 else error("Failed.")
|
||||
::
|
||||
|
||||
// return 3 if int-task fails. if it succeeds, this task will fail aTask
|
||||
<<= intTask mapFailure { (inc: Incomplete) => 3 }
|
||||
intTask := if(shouldSucceed) 5 else error("Failed.")
|
||||
|
||||
// a new task that increments the result of int-task bTask <<= intTask
|
||||
map { \_ + 1 }
|
||||
// return 3 if int-task fails. if it succeeds, this task will fail
|
||||
aTask <<= intTask mapFailure { (inc: Incomplete) => 3 }
|
||||
|
||||
cTask <<= (aTask, bTask) map { (a,b) => a + b } \`\`\` The following
|
||||
table lists the results of each task depending on the initially invoked
|
||||
task:
|
||||
// a new task that increments the result of int-task
|
||||
bTask <<= intTask map { \_ + 1 }
|
||||
|
||||
.. raw:: html
|
||||
cTask <<= (aTask, bTask) map { (a,b) => a + b }
|
||||
|
||||
<table>
|
||||
<th>
|
||||
The following table lists the results of each task depending on the initially invoked task:
|
||||
|
||||
invoked task
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</th> <th>
|
||||
|
||||
int-task result
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</th> <th>
|
||||
|
||||
a-task result
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</th> <th>
|
||||
|
||||
b-task result
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</th> <th>
|
||||
|
||||
c-task result
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</th> <th>
|
||||
|
||||
overall result
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</th>
|
||||
<tr><td>
|
||||
|
||||
int-task
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
failure
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
not run
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
not run
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
not run
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
failure
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td></tr>
|
||||
<tr><td>
|
||||
|
||||
a-task
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
failure
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
success
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
not run
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
not run
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
success
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td></tr>
|
||||
<tr><td>
|
||||
|
||||
b-task
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
failure
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
not run
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
failure
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
not run
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
failure
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td></tr>
|
||||
<tr><td>
|
||||
|
||||
c-task
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
failure
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
success
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
failure
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
failure
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
failure
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td></tr>
|
||||
<tr><td>
|
||||
|
||||
int-task
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
success
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
not run
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
not run
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
not run
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
success
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td></tr>
|
||||
<tr><td>
|
||||
|
||||
a-task
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
success
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
failure
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
not run
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
not run
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
failure
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td></tr>
|
||||
<tr><td>
|
||||
|
||||
b-task
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
success
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
not run
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
success
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
not run
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
success
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td></tr>
|
||||
<tr><td>
|
||||
|
||||
c-task
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
success
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
failure
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
success
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
failure
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
failure
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td></tr>
|
||||
</table>
|
||||
============== =============== ============= ============== ============== ==============
|
||||
invoked task int-task result a-task result b-task result c-task result overall result
|
||||
============== =============== ============= ============== ============== ==============
|
||||
int-task failure not run not run not run failure
|
||||
a-task failure success not run not run success
|
||||
b-task failure not run failure not run failure
|
||||
c-task failure success failure failure failure
|
||||
int-task success not run not run not run success
|
||||
a-task success failure not run not run failure
|
||||
b-task success not run success not run success
|
||||
c-task success failure success failure failure
|
||||
============== =============== ============= ============== ============== ==============
|
||||
|
||||
The overall result is always the same as the root task (the directly
|
||||
invoked task). A ``mapFailure`` turns a success into a failure, and a
|
||||
|
|
@ -813,105 +505,15 @@ with the list of ``Incomplete``\ s. For example:
|
|||
The following table lists the results of invoking ``c-task``, depending
|
||||
on the success of ``aTask`` and ``bTask``:
|
||||
|
||||
.. raw:: html
|
||||
|
||||
<table>
|
||||
<th>
|
||||
|
||||
a-task result
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</th> <th>
|
||||
|
||||
b-task result
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</th> <th>
|
||||
|
||||
c-task result
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</th>
|
||||
<tr> <td>
|
||||
|
||||
failure
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
failure
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
success
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> </tr>
|
||||
<tr> <td>
|
||||
|
||||
failure
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
success
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
success
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> </tr>
|
||||
<tr> <td>
|
||||
|
||||
success
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
failure
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
success
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> </tr>
|
||||
<tr> <td>
|
||||
|
||||
success
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
success
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> <td>
|
||||
|
||||
failure
|
||||
|
||||
.. raw:: html
|
||||
|
||||
</td> </tr>
|
||||
</table>
|
||||
============= ============= =============
|
||||
a-task result b-task result c-task result
|
||||
============= ============= =============
|
||||
failure failure success
|
||||
failure success success
|
||||
success failure success
|
||||
success success failure
|
||||
============= ============= =============
|
||||
|
||||
mapR
|
||||
~~~~
|
||||
|
|
@ -932,10 +534,17 @@ succeeds or fails.
|
|||
|
||||
For example:
|
||||
|
||||
\`\`\`scala intTask := error("Failed.")
|
||||
::
|
||||
|
||||
intTask <<= intTask mapR { case Inc(inc: Incomplete) =>
|
||||
println("Ignoring failure: " + inc) 3 case Value(v) => println("Using
|
||||
successful result: " + v) v }
|
||||
\`\`\ ``This overrides the original``\ int-task\ ``definition so that if the original task fails, the exception is printed and the constant``\ 3\`
|
||||
is returned. If it succeeds, the value is printed and returned.
|
||||
intTask := error("Failed.")
|
||||
|
||||
intTask <<= intTask mapR {
|
||||
case Inc(inc: Incomplete) =>
|
||||
println("Ignoring failure: " + inc)
|
||||
3
|
||||
case Value(v) =>
|
||||
println("Using successful result: " + v)
|
||||
v
|
||||
}
|
||||
|
||||
This overrides the original ``int-task`` definition so that if the original task fails, the exception is printed and the constant ``3`` is returned. If it succeeds, the value is printed and returned.
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ the locations listed above and compile and run tests. The tasks for
|
|||
running tests are ``test`` and ``test-only``. The ``test`` task accepts
|
||||
no command line arguments and runs all tests:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> test
|
||||
|
||||
|
|
@ -47,13 +47,18 @@ test-only
|
|||
The ``test-only`` task accepts a whitespace separated list of test names
|
||||
to run. For example:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> test-only org.example.MyTest1 org.example.MyTest2
|
||||
|
||||
It supports wildcards as well:
|
||||
|
||||
``text > test-only org.example.*Slow org.example.MyTest1`` ## test-quick
|
||||
.. code-block:: console
|
||||
|
||||
> test-only org.example.*Slow org.example.MyTest1
|
||||
|
||||
test-quick
|
||||
----------
|
||||
|
||||
The ``test-quick`` task, like ``test-only``, allows to filter the tests
|
||||
to run to specific tests or wildcards using the same syntax to indicate
|
||||
|
|
@ -108,7 +113,7 @@ Test Framework Arguments
|
|||
Arguments to the test framework may be provided on the command line to
|
||||
the ``test-only`` tasks following a ``--`` separator. For example:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> test-only org.example.MyTest -- -d -S
|
||||
|
||||
|
|
@ -259,7 +264,7 @@ The standard source hierarchy is used:
|
|||
The standard testing tasks are available, but must be prefixed with
|
||||
``it:``. For example,
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> it:test-only org.example.AnIntegrationTest
|
||||
|
||||
|
|
@ -340,7 +345,7 @@ The comments in the integration test section hold, except with
|
|||
|
||||
Test tasks are run by prefixing them with ``fun:``
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> fun:test
|
||||
|
||||
|
|
@ -385,14 +390,14 @@ The key differences are:
|
|||
To run standard unit tests, run ``test`` (or equivalently,
|
||||
``test:test``):
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> test
|
||||
|
||||
To run tests for the added configuration (here, ``"fun"``), prefix it
|
||||
with the configuration name as before:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> fun:test
|
||||
> fun:test-only org.example.AFunTest
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ Compile
|
|||
|
||||
The original use-case was continuous compilation:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> ~ test:compile
|
||||
|
||||
|
|
@ -40,7 +40,7 @@ mailing list.
|
|||
The following will poll for changes to your source code (main or test)
|
||||
and run ``test-only`` for the specified test.
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> ~ test-only example.TestA
|
||||
|
||||
|
|
@ -54,4 +54,6 @@ triggered.
|
|||
The following will poll for source changes and run ``clean`` and
|
||||
``test``.
|
||||
|
||||
``scala > ~; clean; test``
|
||||
.. code-block:: console
|
||||
|
||||
> ~ ;clean ;test
|
||||
|
|
|
|||
|
|
@ -203,11 +203,16 @@ this example I will assume however that the designer chooses
|
|||
``Seq[Writer]``, since it is a reasonable choice both in the above
|
||||
simplified example and in a real-world extension of the above code.
|
||||
|
||||
The client snippets above will now become \`\`\`scala val res:
|
||||
Seq[Writer] = A.openFiles(List(new File("foo.input")))
|
||||
The client snippets above will now become
|
||||
|
||||
val a: Seq[Writer] = new BufferedWriter(new FileWriter("bar.input")) +:
|
||||
A.openFiles(List(new File("foo.input"))) \`\`\`
|
||||
::
|
||||
|
||||
val res: Seq[Writer] =
|
||||
A.openFiles(List(new File("foo.input")))
|
||||
|
||||
val a: Seq[Writer] =
|
||||
new BufferedWriter(new FileWriter("bar.input")) +:
|
||||
A.openFiles(List(new File("foo.input")))
|
||||
|
||||
XXX the rest of the section must be reintegrated or dropped: In general,
|
||||
changing the return type of a method might be source-compatible, for
|
||||
|
|
@ -1,35 +1,17 @@
|
|||
.. toctree::
|
||||
:maxdepth: 2
|
||||
===============
|
||||
Detailed Topics
|
||||
===============
|
||||
|
||||
Artifacts
|
||||
Best-Practices
|
||||
Classpaths
|
||||
Command-Line-Reference
|
||||
Compiler-Plugins
|
||||
Console-Project
|
||||
Cross-Build
|
||||
Detailed-Topics
|
||||
Forking
|
||||
Global-Settings
|
||||
Inspecting-Settings
|
||||
Java-Sources
|
||||
Launcher
|
||||
Library-Management
|
||||
Local-Scala
|
||||
Mapping-Files
|
||||
Migrating-from-sbt-0.7.x-to-0.10.x
|
||||
Parallel-Execution
|
||||
Parsing-Input
|
||||
Paths
|
||||
Process
|
||||
Publishing
|
||||
Resolvers
|
||||
Running-Project-Code
|
||||
Scripts
|
||||
Setup-Notes
|
||||
TaskInputs
|
||||
Tasks
|
||||
Testing
|
||||
Triggered-Execution
|
||||
Update-Report
|
||||
|
||||
This part of the documentation has pages documenting particular sbt topics in detail.
|
||||
Before reading anything in here, you will need the information in the
|
||||
:doc:`Getting Started Guide </Getting-Started/Welcome>` as a foundation.
|
||||
|
||||
Other resources include the :doc:`Examples </Examples/index>` and
|
||||
:doc:`extending sbt </Extending/index>` areas on the wiki, and the
|
||||
`API Documentation <../../api/index.html>`_
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:glob:
|
||||
|
||||
*
|
||||
|
|
|
|||
|
|
@ -1,8 +1,4 @@
|
|||
*Wiki Maintenance Note:* This page has been replaced a couple of times;
|
||||
first by
|
||||
[`Settings <../../sxr/Settings.scala.html>`_\ ]
|
||||
and most recently by [[Getting Started Basic Def]] and [[Getting Started
|
||||
More About Settings]]. It has some obsolete terminology:
|
||||
*Wiki Maintenance Note:* This page has been replaced most recently by :doc:`/Getting-Started/Basic-Def` and :doc:`/Getting-Started/More-About-Settings/`. It has some obsolete terminology:
|
||||
|
||||
- we now avoid referring to build definition as "configuration" to
|
||||
avoid confusion with compile configurations
|
||||
|
|
@ -100,25 +96,51 @@ Notes
|
|||
``~=``, you do not need to use parentheses for either side of the
|
||||
method. Ok:
|
||||
|
||||
``scala libraryDependencies += "junit" % "junit" % "4.8" % "test" libraryDependencies.+=("junit" % "junit" % "4.8" % "test") defaultExcludes ~= (_ || "*~") defaultExcludes ~= (filter => filter || "*~")``
|
||||
::
|
||||
|
||||
libraryDependencies += "junit" % "junit" % "4.8" % "test"
|
||||
|
||||
libraryDependencies.+=("junit" % "junit" % "4.8" % "test")
|
||||
|
||||
defaultExcludes ~= (_ || "*~")
|
||||
|
||||
defaultExcludes ~= (filter => filter || "*~")
|
||||
|
||||
Error:
|
||||
|
||||
\`\`\`console defaultExcludes ~= \_ \|\| "\*~"
|
||||
.. code-block:: console
|
||||
|
||||
error: missing parameter type for expanded function
|
||||
((x\ :math:`1) => defaultExcludes.`\ colon$tilde(x\ :math:`1).`\ bar("*~"))
|
||||
defaultExcludes ~= \_ \|\| "*\ ~" ^ error: value \| is not a member of
|
||||
sbt.Project.Setting[sbt.FileFilter] defaultExcludes ~= \_ \|\| "*~" ^
|
||||
\`\`\`* A block is an expression, with the last statement in the block
|
||||
being the result. For example, the following is an expression:
|
||||
error: missing parameter type for expanded function ((x$1) => defaultExcludes.colon$tilde(x$1).$bar("*~"))
|
||||
defaultExcludes ~= _ || "*~"
|
||||
^
|
||||
error: value | is not a member of sbt.Project.Setting[sbt.FileFilter]
|
||||
defaultExcludes ~= _ || "*~"
|
||||
^
|
||||
|
||||
``scala { val x = 3 def y = 2 x + y }`` An example of using
|
||||
a block to construct a Setting:
|
||||
* A block is an expression, with the last statement in the block being the result. For example, the following is an expression:
|
||||
|
||||
``scala version := { // Define a regular expression to match the current branch val current = """\*\s+(\w+)""".r // Process the output of 'git branch' to get the current branch val branch = "git branch --no-color".lines_!.collect { case current(name) => "-" + name } // Append the current branch to the version. "1.0" + branch.mkString }``
|
||||
\* Remember that blank lines are used to clearly delineate expressions.
|
||||
This happens before the expression is sent to the Scala compiler, so no
|
||||
blank lines are allowed within a block.
|
||||
::
|
||||
|
||||
{
|
||||
val x = 3
|
||||
def y = 2
|
||||
x + y
|
||||
}
|
||||
|
||||
An example of using a block to construct a Setting:
|
||||
|
||||
::
|
||||
|
||||
version := {
|
||||
// Define a regular expression to match the current branch
|
||||
val current = """\*\s+(\w+)""".r
|
||||
// Process the output of 'git branch' to get the current branch
|
||||
val branch = "git branch --no-color".lines_!.collect { case current(name) => "-" + name }
|
||||
// Append the current branch to the version.
|
||||
"1.0" + branch.mkString
|
||||
}
|
||||
|
||||
- Remember that blank lines are used to clearly delineate expressions. This happens before the expression is sent to the Scala compiler, so no blank lines are allowed within a block.
|
||||
|
||||
More Information
|
||||
----------------
|
||||
|
|
@ -146,13 +168,20 @@ More Information
|
|||
separated by blank lines, but each import must be on one line. For
|
||||
example,
|
||||
|
||||
``scala import scala.xml.NodeSeq import math.{abs, pow}`` \* These
|
||||
imports are defined by default in a ``.sbt`` file:
|
||||
::
|
||||
|
||||
\`\`\`scala
|
||||
import scala.xml.NodeSeq
|
||||
import math.{abs, pow}
|
||||
|
||||
import sbt.\_ import Process.\_ import Keys.\_
|
||||
\`\`\ ``In addition, the contents of all public``\ Build\ ``and``\ Plugin\`
|
||||
- These imports are defined by default in a ``.sbt`` file:
|
||||
|
||||
::
|
||||
|
||||
import sbt._
|
||||
import Process._
|
||||
import Keys._
|
||||
|
||||
In addition, the contents of all public ``Build`` and ``Plugin``
|
||||
objects from the full definition are imported.
|
||||
|
||||
sbt uses the blank lines to separate the expressions and then it sends
|
||||
|
|
|
|||
|
|
@ -1,7 +1,8 @@
|
|||
Dormant Pages
|
||||
=============
|
||||
===============
|
||||
Dormant Pages
|
||||
===============
|
||||
|
||||
If you check out the wiki as a git repository, there's a ``Dormant``
|
||||
If you check out the documentation as a git repository, there's a ``Dormant``
|
||||
directory (this one) which contains:
|
||||
|
||||
- "redirect" pages (empty pages that point to some new page). If you
|
||||
|
|
@ -11,7 +12,7 @@ directory (this one) which contains:
|
|||
page into the ``Dormant`` directory.
|
||||
- "clipboard" pages that contain some amount of useful text, that needs
|
||||
to be extracted and organized, maybe moved to existing pages or the
|
||||
FAQ or maybe there's a new page that should exist. Basically content
|
||||
:doc:`/faq` or maybe there's a new page that should exist. Basically content
|
||||
that may be good but needs massaging into the big picture.
|
||||
|
||||
Ideally, pages in here have a note at the top pointing to alternative
|
||||
|
|
@ -19,10 +20,6 @@ content and explaining the status of the page.
|
|||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:glob:
|
||||
|
||||
Basic-Configuration
|
||||
Configurations
|
||||
Full-Configuration
|
||||
Introduction-to-Full-Configurations
|
||||
Needs-New-Home
|
||||
Settings
|
||||
*
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
*Wiki Maintenance Note:* This page has been *mostly* replaced by
|
||||
[[Getting Started Full Def]] and other pages. It has some obsolete
|
||||
:doc:`/Getting-Started/Full-Def` and other pages. It has some obsolete
|
||||
terminology:
|
||||
|
||||
- we now avoid referring to build definition as "configuration" to
|
||||
|
|
@ -84,12 +84,15 @@ An internal project is defined by constructing an instance of
|
|||
``Project``. The minimum information for a new project is its ID string
|
||||
and base directory. For example:
|
||||
|
||||
\`\`\`scala import sbt.\_
|
||||
::
|
||||
|
||||
object MyBuild extends Build { lazy val projectA = Project("a",
|
||||
file("subA")) }
|
||||
\`\`\ ``This constructs a project definition for a project with ID 'a' and located in the``\ /subA\ ``directory. Here,``\ file(...)\ ``is equivalent to``\ new
|
||||
File(...)\` and is resolved relative to the build's base directory.
|
||||
import sbt._
|
||||
|
||||
object MyBuild extends Build {
|
||||
lazy val projectA = Project("a", file("subA"))
|
||||
}
|
||||
|
||||
This constructs a project definition for a project with ID 'a' and located in the ``subA/`` directory. Here, ``file(...)`` is equivalent to ``new File(...)`` and is resolved relative to the build's base directory.
|
||||
There are additional optional parameters to the Project constructor.
|
||||
These parameters configure the project and declare project
|
||||
relationships, as discussed in the next sections.
|
||||
|
|
@ -201,7 +204,11 @@ http/https. These are referred to as external builds and projects. You
|
|||
can reference the root project in an external build with
|
||||
``RootProject``:
|
||||
|
||||
``scala RootProject( file("/home/user/a-project") ) RootProject( uri("git://github.com/dragos/dupcheck.git") )``
|
||||
.. code-block:: text
|
||||
|
||||
RootProject( file("/home/user/a-project") )
|
||||
RootProject( uri("git://github.com/dragos/dupcheck.git") )
|
||||
|
||||
or a specific project within the external build can be referenced using
|
||||
a ``ProjectRef``:
|
||||
|
||||
|
|
@ -261,7 +268,7 @@ aggregation is disabled for ``run``, ``console-quick``, ``console``, and
|
|||
``console-project``. Re-enabling it from the command line for the
|
||||
current project for ``run`` would look like:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> set aggregate in run := true
|
||||
|
||||
|
|
@ -269,7 +276,7 @@ current project for ``run`` would look like:
|
|||
to ``Implicit(true)`` and ``false`` translates to ``Implicit(false)``).
|
||||
Similarly, aggregation can be disabled for the current project using:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> set aggregate in clean := false
|
||||
|
||||
|
|
@ -282,7 +289,7 @@ definition). For example, to declare that ``root/clean`` aggregates
|
|||
``sub1/clean`` and ``sub2/clean`` intransitively (that is, excluding
|
||||
``ext`` even though ``sub2`` aggregates it):
|
||||
|
||||
::
|
||||
.. code-block:: scala
|
||||
|
||||
> set aggregate in clean := Aggregation(Seq(sub1, sub2), transitive = false)
|
||||
|
||||
|
|
@ -298,8 +305,12 @@ A classpath dependency declaration consists of a project reference and
|
|||
an optional configuration mapping. For example, to use project b's
|
||||
``compile`` configuration from project a's ``test`` configuration:
|
||||
|
||||
``scala lazy val a = Project(...) dependsOn(b % "test->compile") lazy val b = Project(...)``
|
||||
``"test->compile"`` may be shortened to ``"test"`` in this case. The
|
||||
::
|
||||
|
||||
lazy val a = Project(...) dependsOn(b % "test->compile")
|
||||
lazy val b = Project(...)
|
||||
|
||||
"test->compile"`` may be shortened to ``"test"`` in this case. The
|
||||
``%`` call may be omitted, in which case the mapping is
|
||||
``"compile->compile"`` by default.
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Snippets of docs that need to move to another page
|
|||
Temporarily change the logging level and configure how stack traces are
|
||||
displayed by modifying the ``log-level`` or ``trace-level`` settings:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> set logLevel := Level.Warn
|
||||
|
||||
|
|
@ -21,7 +21,7 @@ does not have to be listed in your build definition, but it does have to
|
|||
be available in a repository. You can also include the initial command
|
||||
to run after switching to that version. For example:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> ++2.9.1 console-quick
|
||||
...
|
||||
|
|
@ -186,7 +186,7 @@ both the sbt launcher and by projects, by setting the system property
|
|||
|
||||
For example:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
java -Dsbt.ivy.home=/tmp/.ivy2/ ...
|
||||
|
||||
|
|
|
|||
|
|
@ -1,10 +0,0 @@
|
|||
Examples
|
||||
========
|
||||
|
||||
This section of the wiki has example sbt build definitions and code.
|
||||
Contributions are welcome!
|
||||
|
||||
You may want to read the :doc:`Getting Started Guide </Getting-Started/Welcome>`
|
||||
as a foundation for understanding the examples.
|
||||
|
||||
See the sidebar on the right for an index of available examples.
|
||||
|
|
@ -1,8 +1,18 @@
|
|||
.. toctree::
|
||||
:maxdepth: 2
|
||||
========
|
||||
Examples
|
||||
========
|
||||
|
||||
This section of the documentation has example sbt build definitions and code.
|
||||
Contributions are welcome!
|
||||
|
||||
You may want to read the :doc:`Getting Started Guide </Getting-Started/Welcome>`
|
||||
as a foundation for understanding the examples.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
Advanced-Command-Example
|
||||
Advanced-Configurations-Example
|
||||
Full-Configuration-Example
|
||||
Quick-Configuration-Examples
|
||||
|
||||
Advanced-Command-Example
|
||||
Advanced-Configurations-Example
|
||||
Examples
|
||||
Full-Configuration-Example
|
||||
Quick-Configuration-Examples
|
||||
|
|
|
|||
|
|
@ -107,7 +107,7 @@ application.
|
|||
|
||||
``hello.build.properties``
|
||||
|
||||
::
|
||||
.. code-block:: ini
|
||||
|
||||
[scala]
|
||||
version: 2.9.1
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
=============
|
||||
Extending sbt
|
||||
=============
|
||||
|
||||
This part of the wiki has pages documenting sbt "internals," and how to
|
||||
extend them with plugins and commands.
|
||||
|
||||
To understand the pages in here, you'll probably need the
|
||||
:doc:`Getting Started Guide </Getting-Started/Welcome>` as a
|
||||
foundation.
|
||||
|
||||
See the sidebar on the right for an index of topics.
|
||||
|
|
@ -85,7 +85,7 @@ will produce one of the following values for a successful parse
|
|||
(assuming the current Scala version is 2.9.2, the current sbt version is
|
||||
0.12.0, and there are 3 commands left to run):
|
||||
|
||||
::
|
||||
.. code-block:: text
|
||||
|
||||
("scala", "2.9.2")
|
||||
("sbt", "0.12.0")
|
||||
|
|
|
|||
|
|
@ -97,7 +97,7 @@ task-scoping described in this section, if your plugin makes heavy use
|
|||
of the shell. Using configuration-scoping the user could discover your
|
||||
tasks using tab completion:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
coffee:[tab]
|
||||
|
||||
|
|
@ -204,7 +204,7 @@ the raw settings may be reused:
|
|||
|
||||
::
|
||||
|
||||
seq(Project.inConfig(Test)(sbtObfuscate.Plugin.baseObfuscateSettings): _*)
|
||||
Project.inConfig(Test)(sbtObfuscate.Plugin.baseObfuscateSettings)
|
||||
|
||||
Alternatively, one could provide a utility method to load settings in a
|
||||
given configuration:
|
||||
|
|
|
|||
|
|
@ -128,7 +128,7 @@ If sbt is running, do ``reload``.
|
|||
We can change to the plugins project in ``project/`` using
|
||||
``reload plugins``.
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
$ xsbt
|
||||
> reload plugins
|
||||
|
|
@ -139,7 +139,7 @@ Then, we can add dependencies like usual and save them to
|
|||
``project/plugins.sbt``. It is useful, but not required, to run
|
||||
``update`` to verify that the dependencies are correct.
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> set libraryDependencies += "org.clapper" %% "grizzled-scala" % "1.0.4"
|
||||
...
|
||||
|
|
@ -150,7 +150,7 @@ Then, we can add dependencies like usual and save them to
|
|||
|
||||
To switch back to the main project:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> reload return
|
||||
[info] Set current project to root (in build file:/Users/harrah/demo2/)
|
||||
|
|
@ -164,7 +164,15 @@ will be built from source and used on the classpath.
|
|||
|
||||
Edit ``project/project/Build.scala``
|
||||
|
||||
``scala import sbt._ object PluginDef extends Build { override lazy val projects = Seq(root) lazy val root = Project("plugins", file(".")) dependsOn( webPlugin ) lazy val webPlugin = uri("git://github.com/siasia/xsbt-web-plugin") }``
|
||||
::
|
||||
|
||||
import sbt._
|
||||
object PluginDef extends Build {
|
||||
override lazy val projects = Seq(root)
|
||||
lazy val root = Project("plugins", file(".")) dependsOn( webPlugin )
|
||||
lazy val webPlugin = uri("git://github.com/siasia/xsbt-web-plugin")
|
||||
}
|
||||
|
||||
If sbt is running, run ``reload``.
|
||||
|
||||
Note that this approach can be useful used when developing a plugin. A
|
||||
|
|
@ -187,7 +195,7 @@ Grizzled Scala is ready to be used in build definitions. This includes
|
|||
the ``eval`` and ``set`` commands and ``.sbt`` and ``project/*.scala``
|
||||
files.
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> eval grizzled.sys.os
|
||||
|
||||
|
|
@ -282,7 +290,7 @@ A light build definition that uses the plugin might look like:
|
|||
|
||||
::
|
||||
|
||||
seq( MyPlugin.newSettings : _*)
|
||||
MyPlugin.newSettings
|
||||
|
||||
newSetting := "light"
|
||||
|
||||
|
|
@ -349,7 +357,10 @@ Global plugins example
|
|||
The simplest global plugin definition is declaring a library or plugin
|
||||
in ``~/.sbt/plugins/build.sbt``:
|
||||
|
||||
``scala libraryDependencies += "org.example" %% "example-plugin" % "0.1"``
|
||||
::
|
||||
|
||||
libraryDependencies += "org.example" %% "example-plugin" % "0.1"
|
||||
|
||||
This plugin will be available for every sbt project for the current
|
||||
user.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +1,14 @@
|
|||
.. toctree::
|
||||
:maxdepth: 2
|
||||
=============
|
||||
Extending sbt
|
||||
=============
|
||||
|
||||
Build-Loaders
|
||||
Build-State
|
||||
Command-Line-Applications
|
||||
Commands
|
||||
Extending
|
||||
Input-Tasks
|
||||
Plugins-Best-Practices
|
||||
Plugins
|
||||
Settings-Core
|
||||
This part of the documentation has pages on how to extend sbt with plugins and commands.
|
||||
|
||||
To understand the pages in here, you'll need the
|
||||
:doc:`Getting Started Guide </Getting-Started/Welcome>` as a foundation.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:glob:
|
||||
|
||||
*
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
|
||||
=========================
|
||||
Custom Settings and Tasks
|
||||
=========================
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ sbt uses the same directory structure as
|
|||
`Maven <http://maven.apache.org/>`_ for source files by default (all
|
||||
paths are relative to the base directory):
|
||||
|
||||
::
|
||||
.. code-block:: text
|
||||
|
||||
src/
|
||||
main/
|
||||
|
|
@ -55,7 +55,7 @@ sbt files appear in a ``project`` subdirectory.
|
|||
``.sbt`` files to form the complete build definition.
|
||||
See :doc:`.scala build definitions <Full-Def>` for more.
|
||||
|
||||
::
|
||||
.. code-block:: text
|
||||
|
||||
build.sbt
|
||||
project/
|
||||
|
|
@ -79,7 +79,7 @@ Configuring version control
|
|||
Your ``.gitignore`` (or equivalent for other version control systems)
|
||||
should contain:
|
||||
|
||||
::
|
||||
.. code-block:: text
|
||||
|
||||
target/
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ build definition of the build definition project, by creating a
|
|||
|
||||
Here's an illustration.
|
||||
|
||||
::
|
||||
.. code-block:: text
|
||||
|
||||
|
||||
hello/ # your project's base directory
|
||||
|
|
@ -63,7 +63,7 @@ also means that multiple files are allowed.
|
|||
``.sbt`` files are merged into their sibling ``project`` directory.
|
||||
Looking back at the project layout:
|
||||
|
||||
::
|
||||
.. code-block:: text
|
||||
|
||||
|
||||
hello/ # your project's base directory
|
||||
|
|
@ -127,7 +127,7 @@ Now, create ``hello/build.sbt`` as follows:
|
|||
Start up the sbt interactive prompt. Type ``inspect sample-a`` and you
|
||||
should see (among other things):
|
||||
|
||||
::
|
||||
.. code-block:: text
|
||||
|
||||
[info] Setting: java.lang.String = A: in Build.settings in Build.scala
|
||||
[info] Provided by:
|
||||
|
|
@ -135,7 +135,7 @@ should see (among other things):
|
|||
|
||||
and then ``inspect sample-c`` and you should see:
|
||||
|
||||
::
|
||||
.. code-block:: text
|
||||
|
||||
[info] Setting: java.lang.String = C: in build.sbt scoped to ThisBuild
|
||||
[info] Provided by:
|
||||
|
|
@ -149,7 +149,7 @@ definition.
|
|||
|
||||
Now, ``inspect sample-b``:
|
||||
|
||||
::
|
||||
.. code-block:: text
|
||||
|
||||
[info] Setting: java.lang.String = B: in the root project settings in Build.scala
|
||||
[info] Provided by:
|
||||
|
|
@ -161,7 +161,7 @@ Note that ``sample-b`` is scoped to the project
|
|||
|
||||
As you've probably guessed, ``inspect sample-d`` matches ``sample-b``:
|
||||
|
||||
::
|
||||
.. code-block:: text
|
||||
|
||||
[info] Setting: java.lang.String = D: in build.sbt
|
||||
[info] Provided by:
|
||||
|
|
@ -226,7 +226,7 @@ You can switch the sbt interactive prompt to have the build definition
|
|||
project in ``project/`` as the current project. To do so, type
|
||||
``reload plugins``.
|
||||
|
||||
::
|
||||
.. code-block:: text
|
||||
|
||||
> reload plugins
|
||||
[info] Set current project to default-a0e8e4 (in build file:/home/hp/checkout/hello/project/)
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ Now from inside the ``hello`` directory, start sbt and type ``run`` at
|
|||
the sbt interactive console. On Linux or OS X the commands might look
|
||||
like this:
|
||||
|
||||
::
|
||||
.. code-block:: text
|
||||
|
||||
$ mkdir hello
|
||||
$ cd hello
|
||||
|
|
@ -79,11 +79,11 @@ Setting the sbt version
|
|||
You can force a particular version of sbt by creating a file
|
||||
``hello/project/build.properties``. In this file, write:
|
||||
|
||||
::
|
||||
.. code-block:: text
|
||||
|
||||
sbt.version=0.12.0
|
||||
|
||||
From 0.10 onwards, sbt is 99% source compatible from release to release.
|
||||
sbt is 99% source compatible from release to release.
|
||||
Still, setting the sbt version in ``project/build.properties`` avoids
|
||||
any potential confusion.
|
||||
|
||||
|
|
|
|||
|
|
@ -183,7 +183,7 @@ a *dependency* on ``baseDirectory``. If you place the above in
|
|||
``build.sbt`` and run the sbt interactive console, then type
|
||||
``inspect name``, you should see (in part):
|
||||
|
||||
::
|
||||
.. code-block:: text
|
||||
|
||||
[info] Dependencies:
|
||||
[info] *:base-directory
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ and ``hello/bar/build.sbt``. Now ``show version`` at the sbt interactive
|
|||
prompt. You should get something like this (with whatever versions you
|
||||
defined):
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> show version
|
||||
[info] hello-foo/*:version
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
|
||||
=======
|
||||
Running
|
||||
=======
|
||||
|
|
@ -11,7 +12,7 @@ Interactive mode
|
|||
|
||||
Run sbt in your project directory with no arguments:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
$ sbt
|
||||
|
||||
|
|
@ -21,7 +22,7 @@ history!).
|
|||
|
||||
For example, you could type ``compile`` at the sbt prompt:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> compile
|
||||
|
||||
|
|
@ -40,7 +41,7 @@ sbt commands as arguments. For sbt commands that take arguments, pass
|
|||
the command and arguments as one argument to ``sbt`` by enclosing them
|
||||
in quotes. For example,
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
$ sbt clean compile "test-only TestA TestB"
|
||||
|
||||
|
|
@ -57,7 +58,7 @@ automatically recompile or run tests whenever you save a source file.
|
|||
Make a command run when one or more source files change by prefixing the
|
||||
command with ``~``. For example, in interactive mode try:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
> ~ compile
|
||||
|
||||
|
|
|
|||
|
|
@ -132,7 +132,7 @@ Referring to scoped keys when running sbt
|
|||
On the command line and in interactive mode, sbt displays (and parses)
|
||||
scoped keys like this:
|
||||
|
||||
::
|
||||
.. code-block:: text
|
||||
|
||||
{<build-uri>}<project-id>/config:intask::key
|
||||
|
||||
|
|
@ -188,7 +188,7 @@ Inspecting scopes
|
|||
In sbt's interactive mode, you can use the ``inspect`` command to
|
||||
understand keys and their scopes. Try ``inspect test:full-classpath``:
|
||||
|
||||
::
|
||||
.. code-block:: text
|
||||
|
||||
$ sbt
|
||||
> inspect test:full-classpath
|
||||
|
|
|
|||
|
|
@ -22,30 +22,46 @@ Installing sbt
|
|||
==============
|
||||
|
||||
You need two files: `sbt-launch.jar`_ and a script to run it.
|
||||
|
||||
*Note: Relevant information is moving to the `download
|
||||
page <http://www.scala-sbt.org/download.html>`_*
|
||||
The following sections describe how to accomplish this for different systems.
|
||||
|
||||
Yum
|
||||
---
|
||||
|
||||
The sbt package is available from the |typesafe-yum-repo|_. Please install `this rpm`_ to add
|
||||
the typesafe yum repository to your list of approved sources. Then run:
|
||||
``text yum install sbt`` to grab the latest release of sbt.
|
||||
|
||||
\*Note: please make sure to report any issues you may find to the |sbt-launcher-issues|_.
|
||||
.. code-block:: console
|
||||
|
||||
$ yum install sbt
|
||||
|
||||
to grab the latest release of sbt.
|
||||
|
||||
.. note::
|
||||
|
||||
Please make sure to report any issues you may find to the |sbt-launcher-issues|_.
|
||||
|
||||
Apt
|
||||
---
|
||||
|
||||
The sbt package is available from the |typesafe-debian-repo|_. Please install `this deb`_ to add the
|
||||
typesafe debian repository to your list of approved sources. Then run:
|
||||
``text apt-get install sbt`` to grab the latest release of sbt.
|
||||
|
||||
.. code-block: console
|
||||
|
||||
apt-get install sbt
|
||||
|
||||
to grab the latest release of sbt.
|
||||
If sbt cannot be found, dont forget to update your list of repositories.
|
||||
To do so, run: ``text apt-get update``
|
||||
To do so, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ apt-get update
|
||||
|
||||
.. note::
|
||||
|
||||
Please make sure to report any issues you may find to the |sbt-launcher-issues|_.
|
||||
|
||||
\*Note: please make sure to report any issues you may find to the |sbt-launcher-issues|_.
|
||||
|
||||
Gentoo
|
||||
------
|
||||
|
|
@ -55,57 +71,79 @@ merge sbt from binaries:
|
|||
https://github.com/whiter4bbit/overlays/tree/master/dev-java/sbt-bin. To
|
||||
merge sbt from this ebuilds you can do next:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
mkdir -p /usr/local/portage && cd /usr/local/portage
|
||||
git clone git://github.com/whiter4bbit/overlays.git
|
||||
echo "PORTDIR_OVERLAY=$PORTDIR_OVERLAY /usr/local/portage/overlays" >> /etc/make.conf
|
||||
emerge sbt-bin
|
||||
$ mkdir -p /usr/local/portage && cd /usr/local/portage
|
||||
$ git clone git://github.com/whiter4bbit/overlays.git
|
||||
$ echo "PORTDIR_OVERLAY=$PORTDIR_OVERLAY /usr/local/portage/overlays" >> /etc/make.conf
|
||||
$ emerge sbt-bin
|
||||
|
||||
.. note::
|
||||
|
||||
Please report any issues with the ebuild `here <https://github.com/whiter4bbit/overlays/issues>`_.
|
||||
|
||||
Mac
|
||||
---
|
||||
|
||||
Use either `MacPorts <http://macports.org/>`_:
|
||||
``text $ sudo port install sbt``
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ port install sbt
|
||||
|
||||
Or `HomeBrew <http://mxcl.github.com/homebrew/>`_:
|
||||
``text $ brew install sbt``
|
||||
|
||||
There is no need to download the sbt-launch.jar separately with either
|
||||
approach.
|
||||
.. code-block:: console
|
||||
|
||||
$ brew install sbt
|
||||
|
||||
.. note::
|
||||
|
||||
Please make sure to report any issues with these packages to the relevant maintainers.
|
||||
|
||||
|
||||
Windows MSI
|
||||
-----------
|
||||
|
||||
Download and run the `msi`_.
|
||||
You should then be able to run ``sbt`` at the command prompt.
|
||||
|
||||
|
||||
.. note::
|
||||
|
||||
Please make sure to report any issues to the |sbt-launcher-issues|_.
|
||||
|
||||
Manual Installation
|
||||
-------------------
|
||||
|
||||
Windows
|
||||
-------
|
||||
|
||||
You can download the `msi`_
|
||||
|
||||
*or*
|
||||
~~~~~~~
|
||||
|
||||
Create a batch file ``sbt.bat``:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
set SCRIPT_DIR=%~dp0
|
||||
java -Xmx512M -jar "%SCRIPT_DIR%sbt-launch.jar" %*
|
||||
$ set SCRIPT_DIR=%~dp0
|
||||
$ java -Xmx512M -jar "%SCRIPT_DIR%sbt-launch.jar" %*
|
||||
|
||||
and put `sbt-launch.jar`_ in the same directory as the batch file. Put ``sbt.bat`` on your path so
|
||||
that you can launch ``sbt`` in any directory by typing ``sbt`` at the command prompt.
|
||||
|
||||
Unix
|
||||
----
|
||||
~~~~
|
||||
|
||||
Download `sbt-launch.jar`_ and place it in ``~/bin``.
|
||||
|
||||
Create a script to run the jar, by placing this in a file called ``sbt``
|
||||
in your ``~/bin`` directory:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
java -Xms512M -Xmx1536M -Xss1M -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=384M -jar `dirname $0`/sbt-launch.jar "$@"
|
||||
$ java -Xms512M -Xmx1536M -Xss1M -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=384M -jar `dirname $0`/sbt-launch.jar "$@"
|
||||
|
||||
Make the script executable:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
$ chmod u+x ~/bin/sbt
|
||||
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ definition.
|
|||
Recall that for a project ``hello``, its build definition project lives
|
||||
in ``hello/*.sbt`` and ``hello/project/*.scala``:
|
||||
|
||||
::
|
||||
.. code-block:: text
|
||||
|
||||
|
||||
hello/ # your project's base directory
|
||||
|
|
@ -169,7 +169,7 @@ and unpack it with ``jar xf``, you'll see that it contains a text file
|
|||
``sbt/sbt.plugins``. In ``sbt/sbt.plugins`` there's an object name on
|
||||
each line like this:
|
||||
|
||||
::
|
||||
.. code-block:: text
|
||||
|
||||
com.typesafe.sbteclipse.SbtEclipsePlugin
|
||||
|
||||
|
|
@ -199,8 +199,7 @@ object, you don't have to do anything to add them.
|
|||
However, plugins often avoid this because you could not control which
|
||||
projects in a :doc:`multi-project build <Multi-Project>` would use the plugin.
|
||||
|
||||
sbt provides a method called ``seq`` which adds a whole batch of
|
||||
settings at once. So if a plugin has something like this:
|
||||
A whole batch of settings can be added by directly referencing the sequence of settings in a `build.sbt` file. So, if a plugin has something like this:
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -212,16 +211,7 @@ You could add all those settings in ``build.sbt`` with this syntax:
|
|||
|
||||
::
|
||||
|
||||
seq(myPluginSettings: _*)
|
||||
|
||||
If you aren't familiar with the ``_*`` syntax:
|
||||
|
||||
- ``seq`` is defined with a variable number of arguments:
|
||||
``def seq(settings: Setting[_]*)``
|
||||
- ``_*`` converts a sequence into a variable argument list
|
||||
|
||||
Short version: ``seq(myPluginSettings: _*)`` in a ``build.sbt`` adds all
|
||||
the settings in ``myPluginSettings`` to the project.
|
||||
myPluginSettings
|
||||
|
||||
Creating a plugin
|
||||
-----------------
|
||||
|
|
@ -240,7 +230,7 @@ and :doc:`/Extending/Plugins-Best-Practices`.
|
|||
Available Plugins
|
||||
-----------------
|
||||
|
||||
There's :doc:`a list of available plugins </Community/sbt-0.10-plugins-list>`.
|
||||
There's :doc:`a list of available plugins </Community/Community-Plugins>`.
|
||||
|
||||
Some especially popular plugins are:
|
||||
|
||||
|
|
@ -248,7 +238,7 @@ Some especially popular plugins are:
|
|||
- those supporting web frameworks, such as
|
||||
`xsbt-web-plugin <https://github.com/siasia/xsbt-web-plugin>`_.
|
||||
|
||||
:doc:`Check out the list. </Community/sbt-0.10-plugins-list>`
|
||||
:doc:`Check out the list</Community/Community-Plugins>`.
|
||||
|
||||
Next
|
||||
----
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
|
||||
========
|
||||
Welcome!
|
||||
========
|
||||
|
|
|
|||
|
|
@ -1,18 +1,21 @@
|
|||
.. toctree::
|
||||
:maxdepth: 2
|
||||
===============
|
||||
Getting Started
|
||||
===============
|
||||
|
||||
Welcome
|
||||
Setup
|
||||
Hello
|
||||
Directories
|
||||
Running
|
||||
Basic-Def
|
||||
Scopes
|
||||
More-About-Settings
|
||||
Library-Dependencies
|
||||
Full-Def
|
||||
Using-Plugins
|
||||
Multi-Project
|
||||
Custom-Settings
|
||||
Summary
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
Welcome
|
||||
Setup
|
||||
Hello
|
||||
Directories
|
||||
Running
|
||||
Basic-Def
|
||||
Scopes
|
||||
More-About-Settings
|
||||
Library-Dependencies
|
||||
Full-Def
|
||||
Using-Plugins
|
||||
Multi-Project
|
||||
Custom-Settings
|
||||
Summary
|
||||
|
|
|
|||
|
|
@ -0,0 +1,12 @@
|
|||
===================
|
||||
Index with Examples
|
||||
===================
|
||||
|
||||
How to...
|
||||
---------
|
||||
|
||||
This page presents an index of the how-to topics with short examples for many of them.
|
||||
Click ``(details)`` to jump to the full explanation.
|
||||
See also the :doc:`Basic Index <index>`, which omits the examples and just lists the topics.
|
||||
|
||||
.. howtoindex::
|
||||
|
|
@ -0,0 +1,78 @@
|
|||
================
|
||||
Generating files
|
||||
================
|
||||
|
||||
sbt provides standard hooks for adding source or resource generation tasks.
|
||||
|
||||
.. howto::
|
||||
:id: sources
|
||||
:title: Generate sources
|
||||
:type: setting
|
||||
|
||||
sourceGenerators in Compile <+= <your Task[Seq[File]] here>
|
||||
|
||||
A source generation task should generate sources in a subdirectory of ``sourceManaged`` and return a sequence of files generated. The key to add the task to is called ``sourceGenerators``. It should be scoped according to whether the generated files are main (``Compile``) or test (``Test``) sources. This basic structure looks like:
|
||||
|
||||
::
|
||||
|
||||
sourceGenerators in Compile <+= <your Task[Seq[File]] here>
|
||||
|
||||
For example, assuming a method ``def makeSomeSources(base: File): Seq[File]``,
|
||||
|
||||
::
|
||||
|
||||
sourceGenerators in Compile <+= sourceManaged in Compile map { outDir: File =>
|
||||
makeSomeSources(outDir / "demo")
|
||||
}
|
||||
|
||||
As a specific example, the following generates a hello world source file:
|
||||
|
||||
::
|
||||
|
||||
sourceGenerators in Compile <+= sourceManaged in Compile map { dir =>
|
||||
val file = dir / "demo" / "Test.scala"
|
||||
IO.write(file, """object Test extends App { println("Hi") }""")
|
||||
Seq(file)
|
||||
}
|
||||
|
||||
Executing 'run' will print "Hi". Change ``Compile`` to ``Test`` to make it a test source. For efficiency, you would only want to generate sources when necessary and not every run.
|
||||
|
||||
By default, generated sources are not included in the packaged source artifact. To do so, add them as you would other mappings. See ``Adding files to a package``.
|
||||
|
||||
.. howto::
|
||||
:id: resources
|
||||
:title: Generate resources
|
||||
:type: setting
|
||||
|
||||
resourceGenerators in Compile <+= <your Task[Seq[File]] here>
|
||||
|
||||
A resource generation task should generate resources in a subdirectory of ``resourceManaged`` and return a sequence of files generated. The key to add the task to is called ``resourceGenerators``. It should be scoped according to whether the generated files are main (``Compile``) or test (``Test``) resources. This basic structure looks like:
|
||||
|
||||
::
|
||||
|
||||
resourceGenerators in Compile <+= <your Task[Seq[File]] here>
|
||||
|
||||
For example, assuming a method ``def makeSomeResources(base: File): Seq[File]``,
|
||||
|
||||
::
|
||||
|
||||
resourceGenerators in Compile <+= resourceManaged in Compile map { outDir: File =>
|
||||
makeSomeResources(outDir / "demo")
|
||||
}
|
||||
|
||||
As a specific example, the following generates a properties file containing the application name and version:
|
||||
|
||||
::
|
||||
|
||||
resourceGenerators in Compile <+=
|
||||
(resourceManaged in Compile, name, version) map { (dir, n, v) =>
|
||||
val file = dir / "demo" / "myapp.properties"
|
||||
val contents = "name=%s\nversion=%s".format(n,v)
|
||||
IO.write(file, contents)
|
||||
Seq(file)
|
||||
}
|
||||
}
|
||||
|
||||
Change ``Compile`` to ``Test`` to make it a test resource. Normally, you would only want to generate resources when necessary and not every run.
|
||||
|
||||
By default, generated resources are not included in the packaged source artifact. To do so, add them as you would other mappings. See the ``Adding files to a package`` section.
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
=========
|
||||
How to...
|
||||
=========
|
||||
|
||||
This page presents an index of the how-to topics.
|
||||
See also the :doc:`index with examples <Howto>`, which provides brief examples along with the index.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:glob:
|
||||
|
||||
Howto
|
||||
*
|
||||
|
|
@ -0,0 +1,328 @@
|
|||
=================
|
||||
Inspect the build
|
||||
=================
|
||||
|
||||
.. howto::
|
||||
:id: taskhelp
|
||||
:title: Show or search help for a command, task, or setting
|
||||
:type: command
|
||||
|
||||
help compile
|
||||
|
||||
The ``help`` command is used to show available commands and search the help for commands, tasks, or settings.
|
||||
If run without arguments, ``help`` lists the available commands.
|
||||
|
||||
::
|
||||
|
||||
> help
|
||||
|
||||
help Displays this help message or prints detailed help on
|
||||
requested commands (run 'help <command>').
|
||||
about Displays basic information about sbt and the build.
|
||||
reload (Re)loads the project in the current directory
|
||||
...
|
||||
|
||||
::
|
||||
|
||||
> help compile
|
||||
|
||||
If the argument passed to ``help`` is the name of an existing command, setting or task, the help
|
||||
for that entity is displayed. Otherwise, the argument is interpreted as a regular expression that
|
||||
is used to search the help of all commands, settings and tasks.
|
||||
|
||||
The ``tasks`` command is like ``help``, but operates only on tasks.
|
||||
Similarly, the ``settings`` command only operates on settings.
|
||||
|
||||
See also ``help help``, ``help tasks``, and ``help settings``.
|
||||
|
||||
.. howto::
|
||||
:id: listtasks
|
||||
:title: List available tasks
|
||||
:type: command
|
||||
|
||||
tasks
|
||||
|
||||
The ``tasks`` command, without arguments, lists the most commonly used tasks.
|
||||
It can take a regular expression to search task names and descriptions.
|
||||
The verbosity can be increased to show or search less commonly used tasks.
|
||||
See ``help tasks`` for details.
|
||||
|
||||
|
||||
.. howto::
|
||||
:id: listsettings
|
||||
:title: List available settings
|
||||
:type: command
|
||||
|
||||
settings
|
||||
|
||||
The ``settings`` command, without arguments, lists the most commonly used settings.
|
||||
It can take a regular expression to search setting names and descriptions.
|
||||
The verbosity can be increased to show or search less commonly used settings.
|
||||
See ``help settings`` for details.
|
||||
|
||||
.. howto::
|
||||
:id: dependencies
|
||||
:title: Display forward and reverse dependencies of a setting or task
|
||||
:type: command
|
||||
|
||||
inspect compile
|
||||
|
||||
The ``inspect`` command displays several pieces of information about a given setting or task, including
|
||||
the dependencies of a task/setting as well as the tasks/settings that depend on the it. For example,
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> inspect test:compile
|
||||
...
|
||||
[info] Dependencies:
|
||||
[info] test:compile::compile-inputs
|
||||
[info] test:compile::streams
|
||||
[info] Reverse dependencies:
|
||||
[info] test:defined-test-names
|
||||
[info] test:defined-sbt-plugins
|
||||
[info] test:print-warnings
|
||||
[info] test:discovered-main-classes
|
||||
[info] test:defined-tests
|
||||
[info] test:exported-products
|
||||
[info] test:products
|
||||
...
|
||||
|
||||
See the :doc:`/Detailed-Topics/Inspecting-Settings` page for details.
|
||||
|
||||
.. howto::
|
||||
:id: taskdependencytree
|
||||
:title: Display tree of setting/task dependencies
|
||||
:type: command
|
||||
|
||||
inspect compile
|
||||
|
||||
In addition to displaying immediate forward and reverse dependencies as described in the previous section,
|
||||
the ``inspect`` command can display the full dependency tree for a task or setting.
|
||||
For example,
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> inspect tree clean
|
||||
[info] *:clean = Task[Unit]
|
||||
[info] +-*:clean-files = List(<project>/lib_managed, <project>/target)
|
||||
[info] | +-{.}/*:managed-directory = lib_managed
|
||||
[info] | +-*:target = target
|
||||
[info] | +-*:base-directory = <project>
|
||||
[info] | +-*:this-project = Project(id: demo, base: <project>, ...
|
||||
[info] |
|
||||
[info] +-*:clean-keep-files = List(<project>/target/.history)
|
||||
[info] +-*:history = Some(<project>/target/.history)
|
||||
...
|
||||
|
||||
For each task, ``inspect tree`` show the type of the value generated by the task.
|
||||
For a setting, the ``toString`` of the setting is displayed.
|
||||
See the :doc:`/Detailed-Topics/Inspecting-Settings` page for details on the ``inspect`` command.
|
||||
|
||||
.. howto::
|
||||
:id: description
|
||||
:title: Display the description and type of a setting or task
|
||||
:type: command
|
||||
|
||||
help compile
|
||||
|
||||
While the ``help``, ``settings``, and ``tasks`` commands display a description of a task,
|
||||
the ``inspect`` command also shows the type of a setting or task and the value of a setting.
|
||||
For example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> inspect update
|
||||
[info] Task: sbt.UpdateReport
|
||||
[info] Description:
|
||||
[info] Resolves and optionally retrieves dependencies, producing a report.
|
||||
...
|
||||
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> inspect scala-version
|
||||
[info] Setting: java.lang.String = 2.9.2
|
||||
[info] Description:
|
||||
[info] The version of Scala used for building.
|
||||
...
|
||||
|
||||
See the :doc:`/Detailed-Topics/Inspecting-Settings` page for details.
|
||||
|
||||
.. howto::
|
||||
:id: delegates
|
||||
:title: Display the delegation chain of a setting or task
|
||||
:type: command
|
||||
|
||||
inspect compile
|
||||
|
||||
See the :doc:`/Detailed-Topics/Inspecting-Settings` page for details.
|
||||
|
||||
.. howto::
|
||||
:id: related
|
||||
:title: Display related settings or tasks
|
||||
:type: command
|
||||
|
||||
inspect compile
|
||||
|
||||
The ``inspect`` command can help find scopes where a setting or task is defined.
|
||||
The following example shows that different options may be specified to the Scala
|
||||
for testing and API documentation generation.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> inspect scalac-options
|
||||
...
|
||||
[info] Related:
|
||||
[info] compile:doc::scalac-options
|
||||
[info] test:scalac-options
|
||||
[info] */*:scalac-options
|
||||
[info] test:doc::scalac-options
|
||||
|
||||
See the :doc:`/Detailed-Topics/Inspecting-Settings` page for details.
|
||||
|
||||
.. howto::
|
||||
:id: projects
|
||||
:title: Show the list of projects and builds
|
||||
:type: command
|
||||
|
||||
projects
|
||||
|
||||
The ``projects`` command displays the currently loaded projects.
|
||||
The projects are grouped by their enclosing build and the current project is indicated by an asterisk.
|
||||
For example,
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> projects
|
||||
[info] In file:/home/user/demo/
|
||||
[info] * parent
|
||||
[info] sub
|
||||
[info] In file:/home/user/dep/
|
||||
[info] sample
|
||||
|
||||
|
||||
.. howto::
|
||||
:id: session
|
||||
:title: Show the current session (temporary) settings
|
||||
:type: command
|
||||
|
||||
session list
|
||||
|
||||
``session list`` displays the settings that have been added at the command line for the current project. For example,
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> session list
|
||||
1. maxErrors := 5
|
||||
2. scalacOptions += "-explaintypes"
|
||||
|
||||
``session list-all`` displays the settings added for all projects.
|
||||
For details, see ``help session``.
|
||||
|
||||
.. howto::
|
||||
:id: about
|
||||
:title: Show basic information about sbt and the current build
|
||||
:type: command
|
||||
|
||||
about
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> about
|
||||
[info] This is sbt 0.12.0
|
||||
[info] The current project is {file:~/code/sbt.github.com/}default
|
||||
[info] The current project is built against Scala 2.9.2
|
||||
[info] Available Plugins: com.jsuereth.ghpages.GhPages, com.jsuereth.git.GitPlugin, com.jsuereth.sbtsite.SitePlugin
|
||||
[info] sbt, sbt plugins, and build definitions are using Scala 2.9.2
|
||||
|
||||
.. howto::
|
||||
:id: value
|
||||
:title: Show the value of a setting
|
||||
:type: command
|
||||
|
||||
show name
|
||||
|
||||
The ``inspect`` command shows the value of a setting as part of its output, but the ``show`` command is dedicated to this job.
|
||||
It shows the output of the setting provided as an argument. For example,
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> show organization
|
||||
[info] com.github.sbt
|
||||
|
||||
The ``show`` command also works for tasks, described next.
|
||||
|
||||
.. howto::
|
||||
:id: result
|
||||
:title: Show the result of executing a task
|
||||
:type: command
|
||||
|
||||
show update
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> show update
|
||||
... <output of update> ...
|
||||
[info] Update report:
|
||||
[info] Resolve time: 122 ms, Download time: 5 ms, Download size: 0 bytes
|
||||
[info] compile:
|
||||
[info] org.scala-lang:scala-library:2.9.2: ...
|
||||
|
||||
The ``show`` command will execute the task provided as an argument and then print the result.
|
||||
Note that this is different from the behavior of the ``inspect`` command (described in other sections),
|
||||
which does not execute a task and thus can only display its type and not its generated value.
|
||||
|
||||
.. howto::
|
||||
:id: classpath
|
||||
:title: Show the classpath used for compilation or testing
|
||||
:type: command
|
||||
|
||||
show compile:dependency-classpath
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> show compile:dependency-classpath
|
||||
...
|
||||
[info] ArrayBuffer(Attributed(~/.sbt/0.12.0/boot/scala-2.9.2/lib/scala-library.jar))
|
||||
|
||||
For the test classpath,
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> show test:dependency-classpath
|
||||
...
|
||||
[info] ArrayBuffer(Attributed(~/code/sbt.github.com/target/scala-2.9.2/classes), Attributed(~/.sbt/0.12.0/boot/scala-2.9.2/lib/scala-library.jar), Attributed(~/.ivy2/cache/junit/junit/jars/junit-4.8.2.jar))
|
||||
|
||||
.. howto::
|
||||
:id: applications
|
||||
:title: Show the main classes detected in a project
|
||||
:type: command
|
||||
|
||||
show compile:discovered-main-classes
|
||||
|
||||
sbt detects the classes with public, static main methods for use by the ``run`` method and to tab-complete the ``run-main`` method.
|
||||
The ``discovered-main-classes`` task does this discovery and provides as its result the list of class names.
|
||||
For example, the following shows the main classes discovered in the main sources:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> show compile:discovered-main-classes
|
||||
... <runs compile if out of date> ...
|
||||
[info] List(org.example.Main)
|
||||
|
||||
.. howto::
|
||||
:id: tests
|
||||
:title: Show the test classes detected in a project
|
||||
:type: command
|
||||
|
||||
show defined-test-names
|
||||
|
||||
sbt detects tests according to fingerprints provided by test frameworks.
|
||||
The ``defined-test-names`` task provides as its result the list of test names detected in this way.
|
||||
For example,
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> show test:defined-test-names
|
||||
... < runs test:compile if out of date > ...
|
||||
[info] List(org.example.TestA, org.example.TestB)
|
||||
|
|
@ -0,0 +1,211 @@
|
|||
=================
|
||||
Interactive mode
|
||||
=================
|
||||
|
||||
By default, sbt's interactive mode is started when no commands are provided on the command line or when the ``shell`` command is invoked.
|
||||
|
||||
.. howto::
|
||||
:id: basic_completion
|
||||
:title: Use tab completion
|
||||
:type: command
|
||||
|
||||
test-only <TAB>
|
||||
|
||||
As the name suggests, tab completion is invoked by hitting the tab key.
|
||||
Suggestions are provided that can complete the text entered to the left of the current cursor position.
|
||||
Any part of the suggestion that is unambiguous is automatically appended to the current text.
|
||||
Commands typically support tab completion for most of their syntax.
|
||||
|
||||
As an example, entering ``tes`` and hitting tab:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> tes<TAB>
|
||||
|
||||
results in sbt appending a ``t``:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> test
|
||||
|
||||
To get further completions, hit tab again:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> test<TAB>
|
||||
test-frameworks test-listeners test-loader test-only test-options test:
|
||||
|
||||
Now, there is more than one possibility for the next character, so sbt prints the available options.
|
||||
We will select ``test-only`` and get more suggestions by entering the rest of the command and hitting tab twice:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> test-only<TAB><TAB>
|
||||
-- sbt.DagSpecification sbt.EmptyRelationTest sbt.KeyTest sbt.RelationTest sbt.SettingsTest
|
||||
|
||||
The first tab inserts an unambiguous space and the second suggests names of tests to run.
|
||||
The suggestion of `--` is for the separator between test names and options provided to the test framework.
|
||||
The other suggestions are names of test classes for one of sbt's modules.
|
||||
Test name suggestions require tests to be compiled first.
|
||||
If tests have been added, renamed, or removed since the last test compilation, the completions will be out of date until another successful compile.
|
||||
|
||||
|
||||
.. howto::
|
||||
:id: verbose_completion
|
||||
:title: Show more tab completion suggestions
|
||||
:type: text
|
||||
|
||||
Press tab multiple times.
|
||||
|
||||
Some commands have different levels of completion. Hitting tab multiple times increases the verbosity of completions. (Presently, this feature is only used by the ``set`` command.)
|
||||
|
||||
.. howto::
|
||||
:id: show_keybindings
|
||||
:title: Show JLine keybindings
|
||||
:type: commands
|
||||
|
||||
> console-quick
|
||||
scala> :keybindings
|
||||
|
||||
Both the Scala and sbt command prompts use JLine for interaction. The Scala REPL contains a ``:keybindings`` command to show many of the keybindings used for JLine. For sbt, this can be used by running one of the ``console`` commands (``console``, ``console-quick``, or ``console-project``) and then running ``:keybindings``. For example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> console-project
|
||||
[info] Starting scala interpreter...
|
||||
...
|
||||
scala> :keybindings
|
||||
Reading jline properties for default key bindings.
|
||||
Accuracy not guaranteed: treat this as a guideline only.
|
||||
|
||||
1 CTRL-A: move to the beginning of the line
|
||||
2 CTRL-B: move to the previous character
|
||||
...
|
||||
|
||||
|
||||
.. howto::
|
||||
:id: change_keybindings
|
||||
:title: Modify the default JLine keybindings
|
||||
|
||||
JLine, used by both Scala and sbt, uses a configuration file for many of its keybindings.
|
||||
The location of this file can be changed with the system property ``jline.keybindings``.
|
||||
The default keybindings file is included in the sbt launcher and may be used as a starting point for customization.
|
||||
|
||||
|
||||
.. howto::
|
||||
:id: prompt
|
||||
:title: Configure the prompt string
|
||||
:type: setting
|
||||
|
||||
shellPrompt := { (s: State) => System.getProperty("user.name") + "> " }
|
||||
|
||||
By default, sbt only displays `> ` to prompt for a command.
|
||||
This can be changed through the ``shellPrompt`` setting, which has type ``State => String``.
|
||||
:doc:`State </Extending/Build-State>` contains all state for sbt and thus provides access to all build information for use in the prompt string.
|
||||
|
||||
Examples:
|
||||
|
||||
::
|
||||
|
||||
// set the prompt (for this build) to include the project id.
|
||||
shellPrompt in ThisBuild := { state => Project.extract(state).currentRef.project + "> " }
|
||||
|
||||
// set the prompt (for the current project) to include the username
|
||||
shellPrompt := { state => System.getProperty("user.name") + "> " }
|
||||
|
||||
|
||||
.. howto::
|
||||
:id: history
|
||||
:title: Use history
|
||||
:type: command
|
||||
|
||||
!
|
||||
|
||||
Interactive mode remembers history even if you exit sbt and restart it.
|
||||
The simplest way to access history is to press the up arrow key to cycle
|
||||
through previously entered commands. Use ``Ctrl+r`` to incrementally
|
||||
search history backwards. The following commands are supported:
|
||||
|
||||
* ``!`` Show history command help.
|
||||
* ``!!`` Execute the previous command again.
|
||||
* ``!:`` Show all previous commands.
|
||||
* ``!:n`` Show the last n commands.
|
||||
* ``!n`` Execute the command with index ``n``, as shown by the ``!:`` command.
|
||||
* ``!-n`` Execute the nth command before this one.
|
||||
* ``!string`` Execute the most recent command starting with 'string'
|
||||
* ``!?string`` Execute the most recent command containing 'string'
|
||||
|
||||
.. howto::
|
||||
:id: history_file
|
||||
:title: Change the location of the interactive history file
|
||||
:type: setting
|
||||
|
||||
historyPath <<= baseDirectory(t => Some(t / ".history"))
|
||||
|
||||
By default, interactive history is stored in the ``target/`` directory for the current project (but is not removed by a ``clean``).
|
||||
History is thus separate for each subproject.
|
||||
The location can be changed with the ``historyPath`` setting, which has type ``Option[File]``.
|
||||
For example, history can be stored in the root directory for the project instead of the output directory:
|
||||
|
||||
::
|
||||
|
||||
historyPath <<= baseDirectory(t => Some(t / ".history"))
|
||||
|
||||
The history path needs to be set for each project, since sbt will use the value of ``historyPath`` for the current project (as selected by the ``project`` command).
|
||||
|
||||
|
||||
.. howto::
|
||||
:id: share_history
|
||||
:title: Use the same history for all projects
|
||||
:type: setting
|
||||
|
||||
historyPath <<= (target in LocalRootProject) { t => Some(t / ".history") }
|
||||
|
||||
The previous section describes how to configure the location of the history file.
|
||||
This setting can be used to share the interactive history among all projects in a build instead of using a different history for each project.
|
||||
The way this is done is to set ``historyPath`` to be the same file, such as a file in the root project's ``target/`` directory:
|
||||
|
||||
::
|
||||
|
||||
historyPath <<=
|
||||
(target in LocalRootProject) { t =>
|
||||
Some(t / ".history")
|
||||
}
|
||||
|
||||
The ``in LocalRootProject`` part means to get the output directory for the root project for the build.
|
||||
|
||||
.. howto::
|
||||
:id: disable_history
|
||||
:title: Disable interactive history
|
||||
:type: setting
|
||||
|
||||
historyPath := None
|
||||
|
||||
If, for whatever reason, you want to disable history, set ``historyPath`` to ``None`` in each project it should be disabled in:
|
||||
|
||||
historyPath := None
|
||||
|
||||
.. howto::
|
||||
:id: pre_commands
|
||||
:title: Run commands before entering interactive mode
|
||||
:type: batch
|
||||
|
||||
clean compile shell
|
||||
|
||||
Interactive mode is implemented by the ``shell`` command.
|
||||
By default, the ``shell`` command is run if no commands are provided to sbt on the command line.
|
||||
To run commands before entering interactive mode, specify them on the command line followed by ``shell``.
|
||||
For example,
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ sbt clean compile shell
|
||||
|
||||
This runs ``clean`` and then ``compile`` before entering the interactive prompt.
|
||||
If either ``clean`` or ``compile`` fails, sbt will exit without going to the prompt.
|
||||
To enter the prompt whether or not these initial commands succeed, prepend `-shell`, which means to run ``shell`` if any command fails.
|
||||
For example,
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ sbt -shell clean compile shell
|
||||
|
|
@ -0,0 +1,261 @@
|
|||
=========================
|
||||
Configure and use logging
|
||||
=========================
|
||||
|
||||
.. howto::
|
||||
:id: last
|
||||
:title: View the logging output of the previously executed command
|
||||
:type: command
|
||||
|
||||
last
|
||||
|
||||
When a command is run, more detailed logging output is sent to a file than to the screen (by default).
|
||||
This output can be recalled for the command just executed by running ``last``.
|
||||
|
||||
For example, the output of ``run`` when the sources are uptodate is:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> run
|
||||
[info] Running A
|
||||
Hi!
|
||||
[success] Total time: 0 s, completed Feb 25, 2012 1:00:00 PM
|
||||
|
||||
|
||||
The details of this execution can be recalled by running ``last``:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> last
|
||||
[debug] Running task... Cancelable: false, max worker threads: 4, check cycles: false
|
||||
[debug]
|
||||
[debug] Initial source changes:
|
||||
[debug] removed:Set()
|
||||
[debug] added: Set()
|
||||
[debug] modified: Set()
|
||||
[debug] Removed products: Set()
|
||||
[debug] Modified external sources: Set()
|
||||
[debug] Modified binary dependencies: Set()
|
||||
[debug] Initial directly invalidated sources: Set()
|
||||
[debug]
|
||||
[debug] Sources indirectly invalidated by:
|
||||
[debug] product: Set()
|
||||
[debug] binary dep: Set()
|
||||
[debug] external source: Set()
|
||||
[debug] Initially invalidated: Set()
|
||||
[debug] Copy resource mappings:
|
||||
[debug]
|
||||
[info] Running A
|
||||
[debug] Starting sandboxed run...
|
||||
[debug] Waiting for threads to exit or System.exit to be called.
|
||||
[debug] Classpath:
|
||||
[debug] /tmp/e/target/scala-2.9.2/classes
|
||||
[debug] /tmp/e/.sbt/0.12.0/boot/scala-2.9.2/lib/scala-library.jar
|
||||
[debug] Waiting for thread run-main to exit
|
||||
[debug] Thread run-main exited.
|
||||
[debug] Interrupting remaining threads (should be all daemons).
|
||||
[debug] Sandboxed run complete..
|
||||
[debug] Exited with code 0
|
||||
[success] Total time: 0 s, completed Jan 1, 2012 1:00:00 PM
|
||||
|
||||
Configuration of the logging level for the console and for the backing file are described in following sections.
|
||||
|
||||
.. howto::
|
||||
:id: tasklast
|
||||
:title: View the previous logging output of a specific task
|
||||
:type: command
|
||||
|
||||
last compile
|
||||
|
||||
When a task is run, more detailed logging output is sent to a file than to the screen (by default).
|
||||
This output can be recalled for a specific task by running ``last <task>``.
|
||||
For example, the first time ``compile`` is run, output might look like:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> compile
|
||||
[info] Updating {file:/.../demo/}example...
|
||||
[info] Resolving org.scala-lang#scala-library;2.9.2 ...
|
||||
[info] Done updating.
|
||||
[info] Compiling 1 Scala source to .../demo/target/scala-2.9.2/classes...
|
||||
[success] Total time: 0 s, completed Jun 1, 2012 1:11:11 PM
|
||||
|
||||
The output indicates that both dependency resolution and compilation were performed.
|
||||
The detailed output of each of these may be recalled individually.
|
||||
For example,
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> last compile
|
||||
[debug]
|
||||
[debug] Initial source changes:
|
||||
[debug] removed:Set()
|
||||
[debug] added: Set(/home/mark/tmp/a/b/A.scala)
|
||||
[debug] modified: Set()
|
||||
...
|
||||
|
||||
and:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> last update
|
||||
[info] Updating {file:/.../demo/}example...
|
||||
[debug] post 1.3 ivy file: using exact as default matcher
|
||||
[debug] :: resolving dependencies :: example#example_2.9.2;0.1-SNAPSHOT
|
||||
[debug] confs: [compile, runtime, test, provided, optional, compile-internal, runtime-internal, test-internal, plugin, sources, docs, pom]
|
||||
[debug] validate = true
|
||||
[debug] refresh = false
|
||||
[debug] resolving dependencies for configuration 'compile'
|
||||
...
|
||||
|
||||
.. howto::
|
||||
:id: printwarnings
|
||||
:title: Show warnings from the previous compilation
|
||||
:type: command
|
||||
|
||||
print-warnings
|
||||
|
||||
The Scala compiler does not print the full details of warnings by default.
|
||||
Compiling code that uses the deprecated ``error`` method from Predef might generate the following output:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> compile
|
||||
[info] Compiling 1 Scala source to <...>/classes...
|
||||
[warn] there were 1 deprecation warnings; re-run with -deprecation for details
|
||||
[warn] one warning found
|
||||
|
||||
The details aren't provided, so it is necessary to add ``-deprecation`` to the options passed to the compiler (``scalacOptions``) and recompile.
|
||||
An alternative when using Scala 2.10 and later is to run ``print-warnings``.
|
||||
This task will display all warnings from the previous compilation.
|
||||
For example,
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> print-warnings
|
||||
[warn] A.scala:2: method error in object Predef is deprecated: Use sys.error(message) instead
|
||||
[warn] def x = error("Failed.")
|
||||
[warn] ^
|
||||
|
||||
.. howto::
|
||||
:id: level
|
||||
:title: Change the logging level globally
|
||||
:type: command
|
||||
|
||||
set every logLevel := Level.Debug
|
||||
|
||||
The amount of logging is controlled by the ``logLevel`` setting, which takes values from the ``Level`` enumeration.
|
||||
Valid values are ``Error``, ``Warn``, ``Info``, and ``Debug`` in order of increasing verbosity.
|
||||
To change the global logging level, set ``logLevel in Global``.
|
||||
For example, to set it temporarily from the sbt prompt,
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> set logLevel in Global := Level.Warn
|
||||
|
||||
|
||||
- id: tasklevel
|
||||
:title: Change the logging level for a specific task, configuration, or project
|
||||
setting: logLevel in compile := Level.Debug
|
||||
|
||||
The amount of logging is controlled by the ``logLevel`` setting, which takes values from the ``Level`` enumeration.
|
||||
Valid values are ``Error``, ``Warn``, ``Info``, and ``Debug`` in order of increasing verbosity.
|
||||
The logging level may be configured globally, as described in the previous section, or it may be applied to a specific project, configuration, or task.
|
||||
For example, to change the logging level for compilation to only show warnings and errors:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> set logLevel in compile := Level.Warn
|
||||
|
||||
To enable debug logging for all tasks in the current project,
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> set logLevel := Level.Warn
|
||||
|
||||
A common scenario is that after running a task, you notice that you need more information than was shown by default.
|
||||
A ``logLevel`` based solution typically requires changing the logging level and running a task again.
|
||||
However, there are two cases where this is unnecessary.
|
||||
First, warnings from a previous compilation may be displayed using ``print-warnings`` for the main sources or ``test:print-warnings`` for test sources.
|
||||
Second, output from the previous execution is available either for a single task or for in its entirety.
|
||||
See the section on `print-warnings <#printwarnings>`_ and the sections on `previous output <#last>`_.
|
||||
|
||||
|
||||
.. howto::
|
||||
:id: trace
|
||||
:title: Configure printing of stack traces
|
||||
:type: command
|
||||
|
||||
set every traceLevel := 5`
|
||||
|
||||
By default, sbt hides the stack trace of most exceptions thrown during execution.
|
||||
It prints a message that indicates how to display the exception.
|
||||
However, you may want to show more of stack traces by default.
|
||||
|
||||
The setting to configure is ``traceLevel``, which is a setting with an Int value.
|
||||
When ``traceLevel`` is set to a negative value, no stack traces are shown.
|
||||
When it is zero, the stack trace is displayed up to the first sbt stack frame.
|
||||
When positive, the stack trace is shown up to that many stack frames.
|
||||
|
||||
For example, the following configures sbt to show stack traces up to the first sbt frame:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> set every traceLevel := 0
|
||||
|
||||
The ``every`` part means to override the setting in all scopes.
|
||||
To change the trace printing behavior for a single project, configuration, or task, scope ``traceLevel`` appropriately:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> set traceLevel in Test := 5
|
||||
> set traceLevel in update := 0
|
||||
> set traceLevel in ThisProject := -1
|
||||
|
||||
.. howto::
|
||||
:id: nobuffer
|
||||
:title: Print the output of tests immediately instead of buffering
|
||||
:type: setting
|
||||
|
||||
logBuffered := false
|
||||
|
||||
By default, sbt buffers the logging output of a test until the whole class finishes.
|
||||
This is so that output does not get mixed up when executing in parallel.
|
||||
To disable buffering, set the ``logBuffered`` setting to false:
|
||||
|
||||
::
|
||||
|
||||
logBuffered := false
|
||||
|
||||
.. howto::
|
||||
:id: custom
|
||||
:title: Add a custom logger
|
||||
|
||||
The setting ``extraLoggers`` can be used to add custom loggers.
|
||||
A custom logger should implement [AbstractLogger].
|
||||
``extraLoggers`` is a function ``ScopedKey[_] => Seq[AbstractLogger]``.
|
||||
This means that it can provide different logging based on the task that requests the logger.
|
||||
|
||||
::
|
||||
|
||||
extraLoggers ~= { currentFunction =>
|
||||
(key: ScopedKey[_]) => {
|
||||
myCustomLogger(key) +: currentFunction(key)
|
||||
}
|
||||
}
|
||||
|
||||
Here, we take the current function for the setting ``currentFunction`` and provide a new function.
|
||||
The new function prepends our custom logger to the ones provided by the old function.
|
||||
|
||||
.. howto::
|
||||
:id: log
|
||||
:title: Log messages in a task
|
||||
|
||||
The special task ``streams`` provides per-task logging and I/O via a `Streams <../../api/#sbt.std.Streams>`_ instance.
|
||||
To log, a task maps the ``streams`` task and uses its ``log`` member:
|
||||
|
||||
::
|
||||
|
||||
myTask <<= (..., streams) map { (..., s) =>
|
||||
s.log.warn("A warning.")
|
||||
}
|
||||
|
|
@ -0,0 +1,63 @@
|
|||
================
|
||||
Project metadata
|
||||
================
|
||||
|
||||
A project should define ``name`` and ``version``. These will be used in various parts of the build, such as the names of generated artifacts. Projects that are published to a repository should also override ``organization``.
|
||||
|
||||
.. howto::
|
||||
:id: name
|
||||
:type: setting
|
||||
:title: Set the project name
|
||||
|
||||
name := "demo"
|
||||
|
||||
::
|
||||
|
||||
name := "Your project name"
|
||||
|
||||
For published projects, this name is normalized to be suitable for use as an artifact name and dependency ID. This normalized name is stored in ``normalizedName``.
|
||||
|
||||
.. howto::
|
||||
:id: version
|
||||
:type: setting
|
||||
:title: Set the project version
|
||||
|
||||
version := "1.0"
|
||||
|
||||
::
|
||||
|
||||
version := "1.0"
|
||||
|
||||
.. howto::
|
||||
:id: organization
|
||||
:type: setting
|
||||
:title: Set the project organization
|
||||
|
||||
organization := "org.example"
|
||||
|
||||
By convention, this is a reverse domain name that you own, typically one specific to your project. It is used as a namespace for projects.
|
||||
|
||||
A full/formal name can be defined in the ``organizationName`` setting. This is used in the generated pom.xml. If the organization has a web site, it may be set in the ``organizationHomepage`` setting. For example:
|
||||
|
||||
::
|
||||
|
||||
organization := "Example, Inc."
|
||||
|
||||
organizationHomepage := "org.example"
|
||||
|
||||
.. howto::
|
||||
:id: other
|
||||
:type: setting
|
||||
:title: Set the project's homepage and other metadata
|
||||
:reftext: set the project homepage and other metadata used in a published pom.xml
|
||||
|
||||
::
|
||||
|
||||
homepage := Some(url("http://scala-sbt.org"))
|
||||
|
||||
startYear := Some(2008)
|
||||
|
||||
description := "A build tool for Scala."
|
||||
|
||||
licenses += "GPLv2" -> "http://www.gnu.org/licenses/gpl-2.0.html"
|
||||
|
||||
|
|
@ -0,0 +1,82 @@
|
|||
=====================
|
||||
Configure packaging
|
||||
=====================
|
||||
|
||||
.. howto::
|
||||
:id: export
|
||||
:title: Use the packaged jar on classpaths instead of class directory
|
||||
:type: setting
|
||||
|
||||
exportJars := true
|
||||
|
||||
By default, a project exports a directory containing its resources and compiled class files. Set ``exportJars`` to true to export the packaged jar instead. For example,
|
||||
|
||||
::
|
||||
|
||||
exportJars := true
|
||||
|
||||
The jar will be used by ``run``, ``test``, ``console``, and other tasks that use the full classpath.
|
||||
|
||||
|
||||
.. howto::
|
||||
:id: manifest
|
||||
:title: Add manifest attributes
|
||||
:type: setting
|
||||
|
||||
packageOptions in (Compile, packageBin) +=
|
||||
Package.ManifestAttributes( Attributes.Name.SEALED -> "true" )
|
||||
|
||||
By default, sbt constructs a manifest for the binary package from settings such as ``organization`` and ``mainClass``. Additional attributes may be added to the ``packageOptions`` setting scoped by the configuration and package task.
|
||||
|
||||
Main attributes may be added with ``Package.ManifestAttributes``. There are two variants of this method, once that accepts repeated arguments that map an attribute of type ``java.util.jar.Attributes.Name`` to a String value and other that maps attribute names (type String) to the String value.
|
||||
|
||||
For example,
|
||||
|
||||
::
|
||||
|
||||
packageOptions in (Compile, packageBin) +=
|
||||
Package.ManifestAttributes( java.util.jar.Attributes.Name.SEALED -> "true" )
|
||||
|
||||
Other attributes may be added with ``Package.JarManifest``.
|
||||
|
||||
::
|
||||
|
||||
packageOptions in (Compile, packageBin) += {
|
||||
import java.util.jar.{Attributes, Manifest}
|
||||
val manifest = new Manifest
|
||||
manifest.getAttributes("foo/bar/").put(Attributes.Name.SEALED, "false")
|
||||
Package.JarManifest( manifest )
|
||||
}
|
||||
|
||||
Or, to read the manifest from a file:
|
||||
|
||||
::
|
||||
|
||||
packageOptions in (Compile, packageBin) += {
|
||||
val manifest = Using.fileInputStream( in => new java.util.jar.Manifest(in) )
|
||||
Package.JarManifest( manifest )
|
||||
}
|
||||
|
||||
.. howto::
|
||||
:id: name
|
||||
:title: Change the file name of a package
|
||||
|
||||
The ``artifactName`` setting controls the name of generated packages. See the :doc:`/Detailed-Topics/Artifacts` page for details.
|
||||
|
||||
.. howto::
|
||||
:id: contents
|
||||
:title: Modify the contents of the package
|
||||
:type: setting
|
||||
|
||||
mappings in (Compile, packageBin) <+=
|
||||
baseDirectory { dir => ( dir / "example.txt") -> "out/example.txt" }
|
||||
|
||||
The contents of a package are defined by the ``mappings`` task, of type ``Seq[(File,String)]``. The ``mappings`` task is a sequence of mappings from a file to include in the package to the path in the package. See :doc:`/Detailed-Topics/Mapping-Files` for convenience functions for generating these mappings. For example, to add the file ``in/example.txt`` to the main binary jar with the path "out/example.txt",
|
||||
|
||||
::
|
||||
|
||||
mappings in (Compile, packageBin) <+= baseDirectory { base =>
|
||||
(base / "in" / "example.txt") -> "out/example.txt"
|
||||
}
|
||||
|
||||
Note that ``mappings`` is scoped by the configuration and the specific package task. For example, the mappings for the test source package are defined by the ``mappings in (Test, packageSrc)`` task.
|
||||
|
|
@ -0,0 +1,88 @@
|
|||
==================
|
||||
Running commands
|
||||
==================
|
||||
|
||||
.. howto::
|
||||
:id: batch
|
||||
:title: Pass arguments to a command or task in batch mode
|
||||
:type: batch
|
||||
|
||||
clean "test-only org.example.Test" "run-main demo.Main a b c"
|
||||
|
||||
sbt interprets each command line argument provided to it as a command together with the command's arguments.
|
||||
Therefore, to run a command that takes arguments in batch mode, quote the command and its arguments.
|
||||
For example,
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ sbt 'project X' clean '~ compile'
|
||||
|
||||
.. howto::
|
||||
:id: multi
|
||||
:title: Provide multiple commands to run consecutively
|
||||
:type: command
|
||||
|
||||
;clean ;compile
|
||||
|
||||
Multiple commands can be scheduled at once by prefixing each command with a semicolon.
|
||||
This is useful for specifying multiple commands where a single command string is accepted.
|
||||
For example, the syntax for triggered execution is ``~ <command>``.
|
||||
To have more than one command run for each triggering, use semicolons.
|
||||
For example, the following runs ``clean`` and then ``compile`` each time a source file changes:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> ~ ;clean;compile
|
||||
|
||||
.. howto::
|
||||
:id: read
|
||||
:title: Read commands from a file
|
||||
:type: command
|
||||
|
||||
< /path/to/file
|
||||
|
||||
The ``<`` command reads commands from the files provided to it as arguments. Run ``help <`` at the sbt prompt for details.
|
||||
|
||||
.. howto::
|
||||
:id: alias
|
||||
:title: Define an alias for a command or task
|
||||
:type: command
|
||||
|
||||
alias h=help
|
||||
|
||||
The ``alias`` command defines, removes, and displays aliases for commands. Run ``help alias`` at the sbt prompt for details.
|
||||
|
||||
Example usage:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> alias a=about
|
||||
> alias
|
||||
a = about
|
||||
> a
|
||||
[info] This is sbt ...
|
||||
> alias a=
|
||||
> alias
|
||||
> a
|
||||
[error] Not a valid command: a ...
|
||||
|
||||
|
||||
.. howto::
|
||||
:id: eval
|
||||
:title: Quickly evaluate a Scala expression
|
||||
:type: command
|
||||
|
||||
eval 2+2
|
||||
|
||||
The ``eval`` command compiles and runs the Scala expression passed to it as an argument.
|
||||
The result is printed along with its type.
|
||||
For example,
|
||||
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> eval 2+2
|
||||
4: Int
|
||||
|
||||
Variables defined by an ``eval`` are not visible to subsequent ``eval``s, although changes to system properties persist and affect the JVM that is running sbt.
|
||||
Use the Scala REPL (``console`` and related commands) for full support for evaluating Scala code interactively.
|
||||
|
|
@ -0,0 +1,153 @@
|
|||
=========================
|
||||
Configure and use Scala
|
||||
=========================
|
||||
|
||||
By default, sbt's interactive mode is started when no commands are provided on the command line or when the ``shell`` command is invoked.
|
||||
|
||||
.. howto::
|
||||
:id: version
|
||||
:title: Set the Scala version used for building the project
|
||||
:type: setting
|
||||
|
||||
version := "1.0"
|
||||
|
||||
The ``scalaVersion`` configures the version of Scala used for compilation. By default, sbt also adds a dependency on the Scala library with this version. See the next section for how to disable this automatic dependency. If the Scala version is not specified, the version sbt was built against is used. It is recommended to explicitly specify the version of Scala.
|
||||
|
||||
For example, to set the Scala version to "2.9.2",
|
||||
|
||||
::
|
||||
|
||||
scalaVersion := "2.9.2"
|
||||
|
||||
.. howto::
|
||||
:id: noauto
|
||||
:title: Disable the automatic dependency on the Scala library
|
||||
:type: setting
|
||||
|
||||
autoScalaLibrary := false
|
||||
|
||||
sbt adds a dependency on the Scala standard library by default. To disable this behavior, set the ``autoScalaLibrary`` setting to false.
|
||||
|
||||
::
|
||||
|
||||
autoScalaLibrary := false
|
||||
|
||||
.. howto::
|
||||
:id: temporary
|
||||
:title: Temporarily switch to a different Scala version
|
||||
:type: command
|
||||
|
||||
++ 2.8.2
|
||||
|
||||
To set the Scala version in all scopes to a specific value, use the ``++`` command. For example, to temporarily use Scala 2.8.2, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> ++ 2.8.2
|
||||
|
||||
.. howto::
|
||||
:id: local
|
||||
:title: Use a local Scala installation for building a project
|
||||
:type: setting
|
||||
|
||||
scalaHome := Some(file("/path/to/scala/home/"))
|
||||
|
||||
Defining the ``scalaHome`` setting with the path to the Scala home directory will use that Scala installation. sbt still requires ``scalaVersion`` to be set when a local Scala version is used. For example,
|
||||
|
||||
::
|
||||
|
||||
scalaVersion := "2.10.0-local"
|
||||
|
||||
scalaHome := Some(file("/path/to/scala/home/"))
|
||||
|
||||
.. howto::
|
||||
:id: cross
|
||||
:title: Build a project against multiple Scala versions
|
||||
|
||||
See :doc:`cross building </Detailed-Topics/Cross-Build>`.
|
||||
|
||||
.. howto::
|
||||
:id: console-quick
|
||||
:title: Enter the Scala REPL with a project's dependencies on the classpath, but not the compiled project classes
|
||||
:type: command
|
||||
|
||||
console-quick
|
||||
|
||||
The ``console-quick`` action retrieves dependencies and puts them on the classpath of the Scala REPL. The project's sources are not compiled, but sources of any source dependencies are compiled. To enter the REPL with test dependencies on the classpath but without compiling test sources, run ``test:console-quick``. This will force compilation of main sources.
|
||||
|
||||
.. howto::
|
||||
:id: console
|
||||
:title: Enter the Scala REPL with a project's dependencies and compiled code on the classpath
|
||||
:type: command
|
||||
|
||||
console
|
||||
|
||||
The ``console`` action retrieves dependencies and compiles sources and puts them on the classpath of the Scala REPL. To enter the REPL with test dependencies and compiled test sources on the classpath, run ``test:console``.
|
||||
|
||||
.. howto::
|
||||
:id: console-project
|
||||
:title: Enter the Scala REPL with plugins and the build definition on the classpath
|
||||
:type: command
|
||||
|
||||
console-project
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> console-project
|
||||
|
||||
For details, see the :doc:`console-project </Detailed-Topics/Console-Project>` page.
|
||||
|
||||
.. howto::
|
||||
:id: initial
|
||||
:title: Define the initial commands evaluated when entering the Scala REPL
|
||||
:type: setting
|
||||
|
||||
initialCommands in console := """println("Hi!")"""
|
||||
|
||||
Set ``initialCommands in console`` to set the initial statements to evaluate when ``console`` and ``console-quick`` are run. To configure ``console-quick`` separately, use ``initialCommands in consoleQuick``.
|
||||
For example,
|
||||
|
||||
::
|
||||
|
||||
initialCommands in console := """println("Hello from console")"""
|
||||
|
||||
initialCommands in consoleQuick := """println("Hello from console-quick")"""
|
||||
|
||||
The ``console-project`` command is configured separately by ``initialCommands in consoleProject``. It does not use the value from ``initialCommands in console`` by default. For example,
|
||||
|
||||
::
|
||||
|
||||
initialCommands in consoleProject := """println("Hello from console-project")"""
|
||||
|
||||
|
||||
.. howto::
|
||||
:id: embed
|
||||
:title: Use the Scala REPL from project code
|
||||
|
||||
sbt runs tests in the same JVM as sbt itself and Scala classes are not in the same class loader as the application classes. This is also the case in ``console`` and when ``run`` is not forked. Therefore, when using the Scala interpreter, it is important to set it up properly to avoid an error message like:
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
Failed to initialize compiler: class scala.runtime.VolatileBooleanRef not found.
|
||||
** Note that as of 2.8 scala does not assume use of the java classpath.
|
||||
** For the old behavior pass -usejavacp to scala, or if using a Settings
|
||||
** object programmatically, settings.usejavacp.value = true.
|
||||
|
||||
The key is to initialize the Settings for the interpreter using *embeddedDefaults*. For example:
|
||||
|
||||
::
|
||||
|
||||
val settings = new Settings
|
||||
settings.embeddedDefaults[MyType]
|
||||
val interpreter = new Interpreter(settings, ...)
|
||||
|
||||
Here, MyType is a representative class that should be included on the interpreter's classpath and in its application class loader. For more background, see the `original proposal <https://gist.github.com/404272>`_ that resulted in *embeddedDefaults* being added.
|
||||
|
||||
Similarly, use a representative class as the type argument when using the *break* and *breakIf* methods of *ILoop*, as in the following example:
|
||||
|
||||
::
|
||||
|
||||
def x(a: Int, b: Int) = {
|
||||
import scala.tools.nsc.interpreter.ILoop
|
||||
ILoop.breakIf[MyType](a != b, "a" -> a, "b" -> b )
|
||||
}
|
||||
|
|
@ -0,0 +1,70 @@
|
|||
=====================
|
||||
Triggered execution
|
||||
=====================
|
||||
|
||||
.. howto::
|
||||
:id: basic
|
||||
:title: Run a command when sources change
|
||||
:type: command
|
||||
|
||||
~ test
|
||||
|
||||
You can make a command run when certain files change by prefixing the command with ``~``. Monitoring is terminated when ``enter`` is pressed. This triggered execution is configured by the ``watch`` setting, but typically the basic settings ``watch-sources`` and ``poll-interval`` are modified as described in later sections.
|
||||
|
||||
The original use-case for triggered execution was continuous compilation:
|
||||
|
||||
::
|
||||
|
||||
> ~ test:compile
|
||||
|
||||
> ~ compile
|
||||
|
||||
You can use the triggered execution feature to run any command or task, however. The following will poll for changes to your source code (main or test) and run ``test-only`` for the specified test.
|
||||
|
||||
::
|
||||
|
||||
> ~ test-only example.TestA
|
||||
|
||||
.. howto::
|
||||
:id: multi
|
||||
:title: Run multiple commands when sources change
|
||||
:type: command
|
||||
|
||||
~ ;a ;b
|
||||
|
||||
The command passed to ``~`` may be any command string, so multiple commands may be run by separating them with a semicolon. For example,
|
||||
|
||||
::
|
||||
|
||||
> ~ ;a ;b
|
||||
|
||||
This runs ``a`` and then ``b`` when sources change.
|
||||
|
||||
.. howto::
|
||||
:id: sources
|
||||
:title: Configure the sources that are checked for changes
|
||||
:type: setting
|
||||
|
||||
watchSources <+= baseDirectory { _ / "examples.txt" }
|
||||
|
||||
* ``watchSources`` defines the files for a single project that are monitored for changes. By default, a project watches resources and Scala and Java sources.
|
||||
* ``watchTransitiveSources`` then combines the ``watchSources`` for the current project and all execution and classpath dependencies (see :doc:`/Getting-Started/Full-Def` for details on inter-project dependencies).
|
||||
|
||||
To add the file ``demo/example.txt`` to the files to watch,
|
||||
|
||||
::
|
||||
|
||||
watchSources <+= baseDirectory { _ / "demo" / "examples.txt" }
|
||||
|
||||
.. howto::
|
||||
:id: interval
|
||||
:title: Set the time interval between checks for changes to sources
|
||||
:type: setting
|
||||
|
||||
pollInterval := 1000 // in ms
|
||||
|
||||
``pollInterval`` selects the interval between polling for changes in milliseconds. The default value is ``500 ms``. To change it to ``1 s``,
|
||||
|
||||
::
|
||||
|
||||
pollInterval := 1000 // in ms
|
||||
|
|
@ -2,8 +2,8 @@ Index
|
|||
=====
|
||||
|
||||
This is an index of common methods, types, and values you might find in
|
||||
an sbt build definition. For command names, see [[Running\|Getting
|
||||
Started Running]]. For available plugins, see [[sbt 0.10 plugins list]].
|
||||
an sbt build definition. For command names, see :doc:`Running </Getting-Started/Running>`.
|
||||
For available plugins, see :doc:`the plugins list </Community/Community-Plugins>`.
|
||||
|
||||
Values and Types
|
||||
----------------
|
||||
|
|
@ -11,13 +11,13 @@ Values and Types
|
|||
Dependency Management
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- `ModuleID <../../api/sbt/ModuleID.html>`_
|
||||
is the type of a dependency definition. See [[Library Management]].
|
||||
- `Artifact <../../api/sbt/Artifact.html>`_
|
||||
- `ModuleID <../api/sbt/ModuleID.html>`_
|
||||
is the type of a dependency definition. See :doc:`/Detailed-Topics/Library-Management`.
|
||||
- `Artifact <../api/sbt/Artifact.html>`_
|
||||
represents a single artifact (such as a jar or a pom) to be built and
|
||||
published. See [[Library Management]] and [[Artifacts]].
|
||||
published. See :doc:`/Detailed-Topics/Library-Management` and :doc:`/Detailed-Topics/Artifacts`.
|
||||
- A
|
||||
`Resolver <../../api/sbt/Resolver.html>`_
|
||||
`Resolver <../api/sbt/Resolver.html>`_
|
||||
can resolve and retrieve dependencies. Many types of Resolvers can
|
||||
publish dependencies as well. A repository is a closely linked idea
|
||||
that typically refers to the actual location of the dependencies.
|
||||
|
|
@ -26,87 +26,68 @@ Dependency Management
|
|||
- A [ModuleConfiguration] defines a specific resolver to use for a
|
||||
group of dependencies.
|
||||
- A
|
||||
`Configuration <../../api/sbt/Configuration.html>`_
|
||||
`Configuration <../api/sbt/Configuration.html>`_
|
||||
is a useful Ivy construct for grouping dependencies. See
|
||||
[[Configurations]]. It is also used for [[scoping settings\|Getting
|
||||
Started Scopes]].
|
||||
- ``Compile``, ``Test``, ``Runtime``, ``Provided``, and ``Optional``
|
||||
are predefined [[Configurations]].
|
||||
:doc:`/Dormant/Configurations`. It is also used for :doc:`scoping settings </Getting-Started/Scopes>`.
|
||||
- ``Compile``, ``Test``, ``Runtime``, ``Provided``, and ``Optional`` are predefined :doc:`/Dormant/Configurations`.
|
||||
|
||||
Settings and Tasks
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- A
|
||||
`Setting <../../api/sbt/Init$Setting.html>`_
|
||||
- A `Setting <../api/sbt/Init$Setting.html>`_
|
||||
describes how to initialize a specific setting in the build. It can
|
||||
use the values of other settings or the previous value of the setting
|
||||
being initialized.
|
||||
- A
|
||||
`SettingsDefinition <../../api/sbt/Init$SettingsDefinition.html>`_
|
||||
- A `SettingsDefinition <../api/sbt/Init$SettingsDefinition.html>`_
|
||||
is the actual type of an expression in a build.sbt. This allows
|
||||
either a single
|
||||
`Setting <../../api/sbt/Init$Setting.html>`_
|
||||
or a sequence of settings
|
||||
(`SettingList <../../api/sbt/Init$SettingList.html>`_)
|
||||
to be defined at once. The types in a [[Full Configuration]] always
|
||||
use just a plain
|
||||
`Setting <../../api/sbt/Init$Setting.html>`_.
|
||||
- `Initialize <../../api/sbt/Init$Initialize.html>`_
|
||||
either a single `Setting <../api/sbt/Init$Setting.html>`_
|
||||
or a sequence of settings (`SettingList <../api/sbt/Init$SettingList.html>`_)
|
||||
to be defined at once. The types in a :doc:`/Getting-Started/Full-Def` always use just a plain
|
||||
`Setting <../api/sbt/Init$Setting.html>`_.
|
||||
- `Initialize <../api/sbt/Init$Initialize.html>`_
|
||||
describes how to initialize a setting using other settings, but isn't
|
||||
bound to a particular setting yet. Combined with an initialization
|
||||
method and a setting to initialize, it produces a full
|
||||
`Setting <../../api/sbt/Init$Setting.html>`_.
|
||||
- `TaskKey <../../api/sbt/TaskKey.html>`_,
|
||||
`SettingKey <../../api/sbt/SettingKey.html>`_,
|
||||
`Setting <../api/sbt/Init$Setting.html>`_.
|
||||
- `TaskKey <../api/sbt/TaskKey.html>`_,
|
||||
`SettingKey <../api/sbt/SettingKey.html>`_,
|
||||
and
|
||||
`InputKey <../../api/sbt/InputKey.html>`_
|
||||
`InputKey <../api/sbt/InputKey.html>`_
|
||||
are keys that represent a task or setting. These are not the actual
|
||||
tasks, but keys that are used to refer to them. They can be scoped to
|
||||
produce
|
||||
`ScopedTask <../../api/sbt/ScopedTask.html>`_,
|
||||
`ScopedSetting <../../api/sbt/ScopedSetting.html>`_,
|
||||
and
|
||||
`ScopedInput <../../api/sbt/ScopedInput.html>`_.
|
||||
These form the base types that the [[Settings]] implicits add methods
|
||||
to.
|
||||
- `InputTask <../../api/sbt/InputTask.html>`_
|
||||
parses and tab completes user input, producing a task to run.
|
||||
- `Task <../../api/sbt/Task.html>`_ is
|
||||
produce `ScopedTask <../api/sbt/ScopedTask.html>`_,
|
||||
`ScopedSetting <../api/sbt/ScopedSetting.html>`_,
|
||||
and `ScopedInput <../api/sbt/ScopedInput.html>`_.
|
||||
These form the base types that provide the Settings methods.
|
||||
- `InputTask <../api/sbt/InputTask.html>`_ parses and tab completes user input, producing a task to run.
|
||||
- `Task <../api/sbt/Task.html>`_ is
|
||||
the type of a task. A task is an action that runs on demand. This is
|
||||
in contrast to a setting, which is run once at project
|
||||
initialization.
|
||||
in contrast to a setting, which is run once at project initialization.
|
||||
|
||||
Process
|
||||
~~~~~~~
|
||||
|
||||
- A
|
||||
`ProcessBuilder <../../api/sbt/ProcessBuilder.html>`_
|
||||
- A `ProcessBuilder <../api/sbt/ProcessBuilder.html>`_
|
||||
is the type used to define a process. It provides combinators for
|
||||
building up processes from smaller processes.
|
||||
- A
|
||||
`Process <../../api/sbt/Process.html>`_
|
||||
represents the actual forked process.
|
||||
- The `Process companion
|
||||
object <../../api/sbt/Process$.html>`_
|
||||
- A `Process <../api/sbt/Process.html>`_ represents the actual forked process.
|
||||
- The `Process companion object <../api/sbt/Process$.html>`_
|
||||
provides methods for constructing primitive processes.
|
||||
|
||||
Build Structure
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
- `Build <../../api/sbt/Build.html>`_ is
|
||||
the trait implemented for a [[Full Configuration]], which defines
|
||||
- `Build <../api/sbt/Build.html>`_ is
|
||||
the trait implemented for a :doc:`full definition </Getting-Started/Full-Def>`, which defines
|
||||
project relationships and settings.
|
||||
- `Plugin <../../api/sbt/Plugin.html>`_
|
||||
is the trait implemented for sbt [[Plugins]].
|
||||
- `Project <../../api/sbt/Project.html>`_
|
||||
- `Plugin <../api/sbt/Plugin.html>`_ is the trait implemented for sbt :doc:`/Getting-Started/Using-Plugins`.
|
||||
- `Project <../api/sbt/Project.html>`_
|
||||
is both a trait and a companion object that declares a single module
|
||||
in a build. See [[Full Configuration]].
|
||||
- `Keys <../../api/sbt/Keys$.html>`_ is
|
||||
an object that provides all of the built-in keys for settings and
|
||||
tasks.
|
||||
- `State <../../api/sbt/State.html>`_
|
||||
contains the full state for a build. It is mainly used by
|
||||
[[Commands]] and sometimes [[Input Tasks]]. See also [[Build State]].
|
||||
in a build. See :doc:`full definition </Getting-Started/Full-Def>`.
|
||||
- `Keys <../api/sbt/Keys$.html>`_ is
|
||||
an object that provides all of the built-in keys for settings and tasks.
|
||||
- `State <../api/sbt/State.html>`_ contains the full state for a build. It is mainly used by
|
||||
:doc:`/Extending/Commands` and sometimes :doc:`/Extending/Input-Tasks`. See also :doc:`/Extending/Build-State`.
|
||||
|
||||
Methods
|
||||
-------
|
||||
|
|
@ -114,34 +95,28 @@ Methods
|
|||
Settings and Tasks
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
See the [[Getting Started Guide\|Getting Started Basic Def]] for
|
||||
See the :doc:`Getting Started Guide </Getting-Started/Basic-Def>` for
|
||||
details.
|
||||
|
||||
- ``:=``, ``<<=``, ``+=``, ``++=``, ``~=``, ``<+=``, ``<++=`` These
|
||||
construct a
|
||||
`Setting <../../api/sbt/Init$Setting.html>`_,
|
||||
which is the fundamental type in the [[settings\|Getting Started
|
||||
Basic Def]] system.
|
||||
`Setting <../api/sbt/Init$Setting.html>`_,
|
||||
which is the fundamental type in the :doc:`settings </Getting-Started/Basic-Def>` system.
|
||||
- ``map`` This defines a task initialization that uses other tasks or
|
||||
settings. See [[more about settings\|Getting Started More About
|
||||
Settings]]. It is a common name used for many other types in Scala,
|
||||
such as collections.
|
||||
settings. See :doc:`more about settings </Getting-Started/More-About-Settings>`.
|
||||
It is a common name used for many other types in Scala, such as collections.
|
||||
- ``apply`` This defines a setting initialization using other settings.
|
||||
It is not typically written out. See [[more about settings\|Getting
|
||||
Started More About Settings]]. This is a common name in Scala.
|
||||
- ``in`` specifies the
|
||||
`Scope <../../api/sbt/Scope.html>`_ or
|
||||
part of the
|
||||
`Scope <../../api/sbt/Scope.html>`_ of
|
||||
a setting being referenced. See [[scopes\|Getting Started Scopes]].
|
||||
It is not typically written out. See :doc:`more about settings </Getting-Started/More-About-Settings>`.
|
||||
This is a common name in Scala.
|
||||
- ``in`` specifies the `Scope <../api/sbt/Scope.html>`_ or part of the
|
||||
`Scope <../api/sbt/Scope.html>`_ of a setting being referenced. See :doc:`scopes </Getting-Started/Scopes>`.
|
||||
|
||||
File and IO
|
||||
~~~~~~~~~~~
|
||||
|
||||
See
|
||||
`RichFile <../../api/sbt/RichFile.html>`_,
|
||||
`PathFinder <../../api/sbt/PathFinder.html>`_,
|
||||
and [[Paths]] for the full documentation.
|
||||
See `RichFile <../api/sbt/RichFile.html>`_,
|
||||
`PathFinder <../api/sbt/PathFinder.html>`_,
|
||||
and :doc:`/Detailed-Topics/Paths` for the full documentation.
|
||||
|
||||
- ``/`` When called on a single File, this is ``new File(x,y)``. For
|
||||
``Seq[File]``, this is applied for each member of the sequence..
|
||||
|
|
@ -151,17 +126,16 @@ and [[Paths]] for the full documentation.
|
|||
- ``|``, ``||``, ``&&``, ``&``, ``-``, and ``--`` are methods for
|
||||
combining filters, which are often used for selecting ``File``\ s.
|
||||
See
|
||||
`NameFilter <../../api/sbt/NameFilter.html>`_
|
||||
`NameFilter <../api/sbt/NameFilter.html>`_
|
||||
and
|
||||
`FileFilter <../../api/sbt/FileFilter.html>`_.
|
||||
`FileFilter <../api/sbt/FileFilter.html>`_.
|
||||
Note that methods with these names also exist for other types, such
|
||||
as collections (like \`Seq) and
|
||||
`Parser <../../api/sbt/complete/Parser.html>`_
|
||||
(see [[Parsing Input]]).
|
||||
`Parser <../api/sbt/complete/Parser.html>`_
|
||||
(see :doc:`/Detailed-Topics/Parsing-Input`).
|
||||
- ``x`` Used to construct mappings from a ``File`` to another ``File``
|
||||
or to a ``String``. See [[Mapping Files]].
|
||||
- ``get`` forces a
|
||||
`PathFinder <../../api/sbt/PathFinder.html>`_
|
||||
or to a ``String``. See :doc:`/Detailed-Topics/Mapping-Files`.
|
||||
- ``get`` forces a `PathFinder <../api/sbt/PathFinder.html>`_
|
||||
(a call-by-name data structure) to a strict ``Seq[File]``
|
||||
representation. This is a common name in Scala, used by types like
|
||||
``Option``.
|
||||
|
|
@ -169,34 +143,30 @@ and [[Paths]] for the full documentation.
|
|||
Dependency Management
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
See [[Library Management]] for full documentation.
|
||||
See :doc:`/Detailed-Topics/Library-Management` for full documentation.
|
||||
|
||||
- ``%`` This is used to build up a
|
||||
`ModuleID <../../api/sbt/ModuleID.html>`_.
|
||||
`ModuleID <../api/sbt/ModuleID.html>`_.
|
||||
- ``%%`` This is similar to ``%`` except that it identifies a
|
||||
dependency that has been [[cross built\|Cross Build]].
|
||||
dependency that has been :doc:`cross built </Detailed-Topics/Cross-Build>`.
|
||||
- ``from`` Used to specify the fallback URL for a dependency
|
||||
- ``classifier`` Used to specify the classifier for a dependency.
|
||||
- ``at`` Used to define a Maven-style resolver.
|
||||
- ``intransitive`` Marks a
|
||||
`dependency <../../api/sbt/ModuleID.html>`_
|
||||
or
|
||||
`Configuration <../../api/sbt/Configuration.html>`_
|
||||
- ``intransitive`` Marks a `dependency <../api/sbt/ModuleID.html>`_
|
||||
or `Configuration <../api/sbt/Configuration.html>`_
|
||||
as being intransitive.
|
||||
- ``hide`` Marks a
|
||||
`Configuration <../../api/sbt/Configuration.html>`_
|
||||
`Configuration <../api/sbt/Configuration.html>`_
|
||||
as internal and not to be included in the published metadata.
|
||||
|
||||
Parsing
|
||||
~~~~~~~
|
||||
|
||||
These methods are used to build up
|
||||
`Parser <../../api/sbt/complete/Parser.html>`_\ s
|
||||
from smaller
|
||||
`Parser <../../api/sbt/complete/Parser.html>`_\ s.
|
||||
These methods are used to build up `Parser <../api/sbt/complete/Parser.html>`_\ s
|
||||
from smaller `Parser <../api/sbt/complete/Parser.html>`_\ s.
|
||||
They closely follow the names of the standard library's parser
|
||||
combinators. See [[Parsing Input]] for the full documentation. These are
|
||||
used for [[Input Tasks]] and [[Commands]].
|
||||
combinators. See :doc:`/Detailed-Topics/Parsing-Input` for the full documentation. These are
|
||||
used for :doc:`/Extending/Input-Tasks` and :doc:`/Extending/Commands`.
|
||||
|
||||
- ``~``, ``~>``, ``<~`` Sequencing methods.
|
||||
- ``??``, ``?`` Methods for making a Parser optional. ``?`` is postfix.
|
||||
|
|
@ -219,12 +189,11 @@ used for [[Input Tasks]] and [[Commands]].
|
|||
Processes
|
||||
~~~~~~~~~
|
||||
|
||||
These methods are used to [[fork external processes\|Process]]. Note
|
||||
These methods are used to :doc:`fork external processes </Detailed-Topics/Process>`. Note
|
||||
that this API has been included in the Scala standard library for
|
||||
version 2.9.
|
||||
`ProcessBuilder <../../api/sbt/ProcessBuilder.html>`_
|
||||
is the builder type and
|
||||
`Process <../../api/sbt/Process.html>`_
|
||||
`ProcessBuilder <../api/sbt/ProcessBuilder.html>`_
|
||||
is the builder type and `Process <../api/sbt/Process.html>`_
|
||||
is the type representing the actual forked process. The methods to
|
||||
combine processes start with ``#`` so that they share the same
|
||||
precedence.
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue