mirror of https://github.com/sbt/sbt.git
0.10.0
Mark Harrah
parent
d85c98b465
commit
16927664cf
|
|
@ -1,9 +1,9 @@
|
|||
[sbt.Keys]: https://github.com/harrah/xsbt/blob/0.9/main/Keys.scala
|
||||
[Structure]: https://github.com/harrah/xsbt/blob/0.9/main/Structure.scala
|
||||
[Scope]: https://github.com/harrah/xsbt/blob/0.9/main/Scope.scala
|
||||
[Settings]: https://github.com/harrah/xsbt/blob/0.9/util/collection/Settings.scala
|
||||
[Attributes]: https://github.com/harrah/xsbt/blob/0.9/util/collection/Attributes.scala
|
||||
[Defaults]: https://github.com/harrah/xsbt/blob/0.9/main/Defaults.scala
|
||||
[sbt.Keys]: http://harrah.github.com/xsbt/latest/api/sbt/Keys$.html
|
||||
[Scoped]: http://harrah.github.com/xsbt/latest/api/sbt/Scoped$.html
|
||||
[Scope]: http://harrah.github.com/xsbt/latest/api/sbt/Scope$.html
|
||||
[Settings]: http://harrah.github.com/xsbt/latest/sxr/Settings.scala.html
|
||||
[Attributes]: http://harrah.github.com/xsbt/latest/sxr/Attributes.scala.html
|
||||
[Defaults]: https://github.com/harrah/xsbt/latest/sxr/Defaults.scala.html
|
||||
|
||||
A build definition is written in Scala. There are two types of definitions: light and full. A light definition is a quick way of configuring a build. It consists of a list of expressions describing project settings.
|
||||
|
||||
|
|
@ -158,7 +158,7 @@ In addition, the contents of all public `Build` and `Plugin` objects from the fu
|
|||
|
||||
Each expression describes an initialization operation. The simplest operation is context-free assignment using `:=`. That is, no outside information is used to determine the setting value. Operations other than `:=` are implemented in terms of `<<=`. The `<<=` method specifies an operation that requires other settings to be initialized and uses their values to define a new setting.
|
||||
|
||||
The target (left side value) of a method like `:=` identifies one of the constructs in sbt: settings, tasks, and input tasks. It is not an actual setting or task, but a key representing a setting or task. A setting is a value assigned when a project is loaded. A task is a unit of work that is run on-demand zero or more times after a project is loaded and also produces a value. An input task, previously known as a Method Task in 0.7 and earlier, accepts an input string and produces a task to be run. The renaming is because it can accept arbitrary input in 0.9 and not just a space-delimited sequence of arguments like in 0.7.
|
||||
The target (left side value) of a method like `:=` identifies one of the constructs in sbt: settings, tasks, and input tasks. It is not an actual setting or task, but a key representing a setting or task. A setting is a value assigned when a project is loaded. A task is a unit of work that is run on-demand zero or more times after a project is loaded and also produces a value. An input task, previously known as a Method Task in 0.7 and earlier, accepts an input string and produces a task to be run. The renaming is because it can accept arbitrary input in 0.10 and not just a space-delimited sequence of arguments like in 0.7.
|
||||
|
||||
A construct (setting, task, or input task) is identified by a scoped key, which is a pair `(Scope, AttributeKey[T])`. An `AttributeKey` associates a name with a type and is a typesafe key for use in an `AttributeMap`. Attributes are best illustrated by the `get` and `put` methods on `AttributeMap`:
|
||||
```scala
|
||||
|
|
@ -184,7 +184,7 @@ val helloArgs = InputKey[String]("hello-with-args")
|
|||
|
||||
In the basic expression `name := "asdf"`, the `:=` method is implicitly available for a `SettingKey` and accepts an argument that conforms to the type parameter of name, which is String.
|
||||
|
||||
The high-level API for constructing settings is defined in [Structure]. Scopes are defined in [Scope]. The underlying engine is in [Settings] and the heterogeneous map is in [Attributes].
|
||||
The high-level API for constructing settings is defined in [Scoped]. Scopes are defined in [Scope]. The underlying engine is in [Settings] and the heterogeneous map is in [Attributes].
|
||||
|
||||
Built-in keys are in
|
||||
[Keys] and default settings are defined in [Defaults].
|
||||
12
Changes.md
12
Changes.md
|
|
@ -1,21 +1,21 @@
|
|||
### 0.7.7 to 0.10.0 (under development, currently at 0.9.10)
|
||||
### 0.7.7 to 0.10.0
|
||||
|
||||
**Major redesign, only prominent changes listed.**
|
||||
|
||||
* Project definitions in Scala 2.8.1
|
||||
* New configuration system: [[Quick Configuration Examples]]
|
||||
* New configuration system: [[Quick Configuration Examples]], [[Full Configuration]], and [[Basic Configuration]]
|
||||
* New task engine: [[Tasks]]
|
||||
* New multiple project support: [[Full Configuration]]
|
||||
* More aggressive incremental recompilation for both Java and Scala sources
|
||||
* Merged plugins and processors into improved plugins system: [[Plugins]]
|
||||
* [[Web application|https://github.com/siasia/xsbt-web-plugin]] and webstart support moved plugins instead of core features
|
||||
* [[Web application|https://github.com/siasia/xsbt-web-plugin]] and webstart support moved to plugins instead of core features
|
||||
* Fixed all of the issues in (Google Code) issue #44
|
||||
* Dependencies automatically updated when configuration changes
|
||||
* Managed dependencies automatically updated when configuration changes
|
||||
* `update-sbt-classifiers` and `update-classifiers` tasks for retrieving sources and/or javadocs for dependencies, transitively
|
||||
* Improved artifact handling and configuration [[Artifacts]]
|
||||
* Tab completion parser combinators for commands and input tasks: [[Commands]]
|
||||
* No project creation prompts
|
||||
* (pending) Moved to GitHub: <http://github.com/harrah/sbt>
|
||||
* No project creation prompts anymore
|
||||
* Moved to GitHub: <http://github.com/harrah/xsbt>
|
||||
|
||||
### 0.7.5 to 0.7.7
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ This page discusses how sbt builds up classpaths for different actions, like `co
|
|||
|
||||
# Basics
|
||||
|
||||
In sbt 0.9, classpaths now include the Scala library and (when declared as a dependency) the Scala compiler. Classpath-related settings and tasks typically provide a value of type `Classpath`. This is an alias for `Seq[Attributed[File]]`. `Attributed` is a type that associates a heterogeneous map with each classpath entry. Currently, this allows sbt to pair the `Analysis` resulting from compilation with the corresponding classpath entry. This helps support multi-project incremental recompilation.
|
||||
In sbt 0.10.0 and later, classpaths now include the Scala library and (when declared as a dependency) the Scala compiler. Classpath-related settings and tasks typically provide a value of type `Classpath`. This is an alias for `Seq[Attributed[File]]`. `Attributed` is a type that associates a heterogeneous map with each classpath entry. Currently, this allows sbt to pair the `Analysis` resulting from compilation with the corresponding classpath entry. This helps support multi-project incremental recompilation.
|
||||
|
||||
To explicitly extract the raw `Seq[File]`, use the `files` method implicitly added to `Classpath`:
|
||||
```scala
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
[State]: http://harrah.github.com/xsbt/latest/api/sbt/State$.html
|
||||
|
||||
# Commands
|
||||
|
||||
# Introduction
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
# Introduction
|
||||
|
||||
Different versions of Scala can be binary incompatible, despite maintaining source compatibility. This can be true even for versions with the same minor number, such as 2.7.2 and 2.7.4. This page describes how to use `sbt` to build and publish your project against multiple versions of Scala and how to use libraries that have done the same.
|
||||
Different versions of Scala can be binary incompatible, despite maintaining source compatibility. This page describes how to use `sbt` to build and publish your project against multiple versions of Scala and how to use libraries that have done the same.
|
||||
|
||||
# Publishing Conventions
|
||||
|
||||
|
|
@ -41,10 +41,10 @@ A typical way to use this feature is to do development on a single Scala version
|
|||
|
||||
you make your project available to users for different versions of Scala. See [[Publishing]] for more details on publishing your project.
|
||||
|
||||
In order to make this process as quick as possible, different output and managed dependency directories are used for different versions of Scala. For example, when building against Scala 2.7.7,
|
||||
In order to make this process as quick as possible, different output and managed dependency directories are used for different versions of Scala. For example, when building against Scala 2.8.1,
|
||||
|
||||
* `./target/` becomes `./target/scala_2.7.7/`
|
||||
* `./lib_managed/` becomes `./lib_managed/scala_2.7.7/`
|
||||
* `./target/` becomes `./target/scala_2.8.1/`
|
||||
* `./lib_managed/` becomes `./lib_managed/scala_2.8.1/`
|
||||
|
||||
Packaged jars, wars, and other artifacts have `_<scala-version>` appended to the normal artifact ID as mentioned in the Publishing Conventions section above.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Using the Configuration System
|
||||
|
||||
Central to sbt 0.9 is the new configuration system, which is designed to enable extensive customization.
|
||||
Central to sbt 0.10 is the new configuration system, which is designed to enable extensive customization.
|
||||
The goal of this page is to explain the general model behind the configuration system and how to work with it.
|
||||
[[Basic Configuration]] describes how to define settings; this page describes interacting with them and exploring them at the command line.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,24 +1,24 @@
|
|||
[sbt-launch.jar]: http://repo.typesafe.com/typesafe/ivy-releases/org.scala-tools.sbt/sbt-launch/0.9.10/sbt-launch.jar
|
||||
[sbt-launch.jar]: http://repo.typesafe.com/typesafe/ivy-releases/org.scala-tools.sbt/sbt-launch/0.10.0/sbt-launch.jar
|
||||
[mailing list]: http://groups.google.com/group/simple-build-tool/
|
||||
[xsbt-web-plugin]: https://github.com/siasia/xsbt-web-plugin
|
||||
|
||||
The assumption here is that you are familiar with SBT 0.7.x but new to 0.9.x.
|
||||
The assumption here is that you are familiar with sbt 0.7.x but new to 0.10.x.
|
||||
|
||||
0.9.x's many new capabilities can be a bit overwhelming, but this page should help you migrate to 0.9.x with a minimum of fuss.
|
||||
sbt 0.10's many new capabilities can be a bit overwhelming, but this page should help you migrate to 0.10 with a minimum of fuss.
|
||||
|
||||
## Why move to 0.9.x?
|
||||
## Why move to 0.10?
|
||||
|
||||
1. Faster builds (because it is smarter at re-compiling only what it must)
|
||||
1. Easier configuration. For simple projects a single `build.sbt` file in your root directory is easier to create than `project/build/MyProject.scala` was.
|
||||
1. No more `lib_managed` directory, reducing disk usage and avoiding backup and version control hassles.
|
||||
1. `update` is now much faster and it's invoked automatically by SBT.
|
||||
1. `update` is now much faster and it's invoked automatically by sbt.
|
||||
1. Terser output. (Yet you can ask for more details if something goes wrong.)
|
||||
|
||||
# Step 1: Install SBT 0.9.x
|
||||
# Step 1: Install sbt 0.10.0
|
||||
|
||||
Builds are announced here: [[https://groups.google.com/forum/#!forum/simple-build-tool]]. As I write the most recent is `0.9.10` and can be downloaded here: [sbt-launch.jar].
|
||||
The most recent release is `0.10.0` and can be downloaded here: [sbt-launch.jar].
|
||||
|
||||
You can run 0.9.x the same way that you run 0.7.x, either simply:
|
||||
You can run 0.10.x the same way that you run 0.7.x, either simply:
|
||||
|
||||
java -jar sbt-launch.jar
|
||||
|
||||
|
|
@ -28,21 +28,21 @@ Or (as most users do) with a shell script like:
|
|||
if test -f ~/.sbtconfig; then
|
||||
. ~/.sbtconfig
|
||||
fi
|
||||
exec java -Xmx512M ${SBT_OPTS} -jar ~/local/sbt/sbt-launch-0.9.10.jar "$@"
|
||||
exec java -Xmx512M ${SBT_OPTS} -jar ~/local/sbt/sbt-launch-0.10.0.jar "$@"
|
||||
|
||||
Note, in this script that I have renamed the `sbt-launch.jar` file with the version so that I can continue to use my 0.7.x version for projects that haven't been migrated. I called this script `sbt9`.
|
||||
|
||||
For more details see: [[Setup]].
|
||||
|
||||
# Step 2: A simple technique for switching an existing project
|
||||
# Step 2: A technique for switching an existing project
|
||||
|
||||
Here is a simple technique for switching an existing project to 0.9.x while retaining the ability to switch back again at will. Some builds, such as those with subprojects, are not suited for this technique, but if you learn how to transition a simple project it will help you do a more complex one next.
|
||||
Here is a technique for switching an existing project to 0.10 while retaining the ability to switch back again at will. Some builds, such as those with subprojects, are not suited for this technique, but if you learn how to transition a simple project it will help you do a more complex one next.
|
||||
|
||||
## Preserve `project/` for 0.7.x project
|
||||
|
||||
Rename your `project/` directory to something like `project-old`. This will hide it from SBT 0.9.x but keep it in case you want to switch back to 0.7.x.
|
||||
Rename your `project/` directory to something like `project-old`. This will hide it from sbt 0.10 but keep it in case you want to switch back to 0.7.x.
|
||||
|
||||
## Create `build.sbt` for 0.9.x
|
||||
## Create `build.sbt` for 0.10
|
||||
|
||||
Create a `build.sbt` file in the root directory of your project. See [[Quick-Configuration-Examples]] for simple examples. [[Basic-Configuration]] has more details, but don't get bogged down in detail you probably won't need at first! If you have a simple project then converting your existing project file to this format is largely a matter of re-writing your dependencies and maven archive declarations in a modified yet familiar syntax.
|
||||
|
||||
|
|
@ -75,24 +75,24 @@ scalaVersion := "2.8.1"
|
|||
Currently, a `project/build.properties` is still needed to explicitly select the sbt version. For example:
|
||||
|
||||
```text
|
||||
sbt.version=0.9.10
|
||||
sbt.version=0.10.0
|
||||
```
|
||||
|
||||
## Run SBT 0.9.x
|
||||
## Run sbt 0.10
|
||||
|
||||
Now launch sbt. If you're lucky it works and you're done. For help debugging, see below.
|
||||
|
||||
## Switching back to SBT 0.7.x
|
||||
## Switching back to sbt 0.7.x
|
||||
|
||||
If you get stuck and want to switch back, you can leave your `build.sbt` file alone. SBT 0.7.x will not understand or notice it. Just rename your 0.9.x `project` directory to something like `project09` and rename the backup of your old project from `project-old` to `project` again.
|
||||
If you get stuck and want to switch back, you can leave your `build.sbt` file alone. sbt 0.7.x will not understand or notice it. Just rename your 0.10.x `project` directory to something like `project10` and rename the backup of your old project from `project-old` to `project` again.
|
||||
|
||||
# Useful hints and tips
|
||||
|
||||
## Where has `lib_managed` gone?
|
||||
|
||||
By default, SBT 0.9.x loads managed libraries from your ivy cache without copying them to a `lib_managed` directory. This fixes some bugs with the previous solution and keeps your project directory small. If you want to insulate your builds from the ivy cache being cleared, set `retrieveManaged := true` and the dependencies will be copied to `lib_managed` as a build-local cache (while avoiding the issues of `lib_managed` in 0.7.x).
|
||||
By default, sbt 0.10 loads managed libraries from your ivy cache without copying them to a `lib_managed` directory. This fixes some bugs with the previous solution and keeps your project directory small. If you want to insulate your builds from the ivy cache being cleared, set `retrieveManaged := true` and the dependencies will be copied to `lib_managed` as a build-local cache (while avoiding the issues of `lib_managed` in 0.7.x).
|
||||
|
||||
This does mean that existing solutions for sharing libraries with your favoured IDE may not work. There are 0.9.x plugins for IDEs being developed:
|
||||
This does mean that existing solutions for sharing libraries with your favoured IDE may not work. There are 0.10.x plugins for IDEs being developed:
|
||||
|
||||
* IntelliJ IDEA: [[https://github.com/teigen/plugins]]
|
||||
* Netbeans: [[https://github.com/remeniuk/sbt-netbeans-plugin]]
|
||||
|
|
@ -122,7 +122,7 @@ Note that some commands now require an additional space after the initial symbol
|
|||
|
||||
## My last command didn't work but I can't see an explanation. Why?
|
||||
|
||||
SBT 0.9.x by default suppresses most stack traces and debugging information. It has the nice side effect of giving you less noise on screen, but as a newcomer it can leave you lost for explanation. To see the previous output of a command at a higher verbosity, type `last <task>` where `<task>` is the task that failed or that you want to view detailed output for. For example, if you find that your `update` fails to load all the dependencies as you expect you can enter:
|
||||
sbt 0.10 by default suppresses most stack traces and debugging information. It has the nice side effect of giving you less noise on screen, but as a newcomer it can leave you lost for explanation. To see the previous output of a command at a higher verbosity, type `last <task>` where `<task>` is the task that failed or that you want to view detailed output for. For example, if you find that your `update` fails to load all the dependencies as you expect you can enter:
|
||||
|
||||
```text
|
||||
> last update
|
||||
|
|
@ -132,13 +132,13 @@ and it will display the full output from the last run of the `update` command.
|
|||
|
||||
## Why have the resolved dependencies in a multi-module project changed?
|
||||
|
||||
SBT 0.9.x fixes a flaw in how dependencies get resolved in multi-module projects. This change ensures that only one version of a library appears on a classpath.
|
||||
sbt 0.10 fixes a flaw in how dependencies get resolved in multi-module projects. This change ensures that only one version of a library appears on a classpath.
|
||||
|
||||
Use `last update` to view the debugging output for the last `update` run. Use `show update` to view a summary of files comprising managed classpaths.
|
||||
|
||||
## My tests all run really fast but some are broken that weren't before!
|
||||
|
||||
Be aware that compilation and tests run in parallel by default in SBT 0.9.x. If your test code isn't thread-safe then you may want to change this behaviour by adding one of the following to your `build.sbt`:
|
||||
Be aware that compilation and tests run in parallel by default in sbt 0.10. If your test code isn't thread-safe then you may want to change this behaviour by adding one of the following to your `build.sbt`:
|
||||
|
||||
```scala
|
||||
// Execute tests in the current project serially.
|
||||
|
|
@ -153,7 +153,7 @@ parallelExecution := false
|
|||
|
||||
`warn`, `info`, `debug` and `error` don't work any more.
|
||||
|
||||
The new syntax in the SBT 0.9.x shell is:
|
||||
The new syntax in the sbt 0.9.x shell is:
|
||||
```text
|
||||
> set logLevel := Level.Warn
|
||||
```
|
||||
|
|
@ -170,9 +170,9 @@ Web application support was split out into a plugin. See the [xsbt-web-plugin]
|
|||
|
||||
Web Start support still needs a new home. Please consider adopting it! Use the [mailing list] for guidance.
|
||||
|
||||
## How are inter-project dependencies different in 0.9.x?
|
||||
## How are inter-project dependencies different in 0.10?
|
||||
|
||||
In 0.9.x, there are three types of [[project dependencies|Full Configuration]] (classpath, execution, and configuration) and they are independently defined. These were combined in a single dependency type in 0.7.x. A declaration like:
|
||||
In 0.10, there are three types of [[project dependencies|Full Configuration]] (classpath, execution, and configuration) and they are independently defined. These were combined in a single dependency type in 0.7.x. A declaration like:
|
||||
|
||||
```scala
|
||||
lazy val a = project("a", "A")
|
||||
|
|
@ -185,8 +185,9 @@ meant that the `B` project had a classpath and execution dependency on `A` and `
|
|||
1. Execution: A task executed on `B` would be executed on `A` first.
|
||||
1. Configuration: For some settings, if they were not overridden in `A`, they would default to the value provided in `B`.
|
||||
|
||||
In 0.9.x, declare the specific type of dependency you want. See [[Full Configuration]] for details.
|
||||
In 0.10, declare the specific type of dependency you want. See [[Full Configuration]] for details.
|
||||
|
||||
## Were can I find Plugin for 0.9.x?
|
||||
## Where can I find plugins for 0.10?
|
||||
|
||||
See [[sbt 0.10 plugins list]] for a list of currently available plugins.
|
||||
|
||||
See [[sbt 0.9.x plugins list]] for a list of currently available plugins.
|
||||
|
|
@ -22,7 +22,7 @@ Below is a running list of potential areas of contribution. This list may becom
|
|||
4. Dependency management is a general area. Working on Apache Ivy itself is another way to help. For example, I'm pretty sure Ivy is fundamentally single threaded. Either a) it's not and you can fix sbt to take advantage of this or b) make Ivy multi-threaded and faster at resolving dependencies.
|
||||
5. If you like parsers, sbt commands and input tasks are written using custom parser combinators that provide tab completion and error handling. Among other things, the efficiency could be improved.
|
||||
6. The javap task hasn't been reintegrated
|
||||
7. Implement enhanced 0.9-style warn/debug/info/error/trace commands. Currently, you set it like any other setting:
|
||||
7. Implement enhanced 0.10-style warn/debug/info/error/trace commands. Currently, you set it like any other setting:
|
||||
```scala
|
||||
set logLevel := Level.Warn
|
||||
or
|
||||
|
|
@ -33,6 +33,6 @@ Below is a running list of potential areas of contribution. This list may becom
|
|||
warn test:run
|
||||
```
|
||||
Also, trace is currently an integer, but should really be an abstract data type.
|
||||
8. There is more aggressive incremental compilation in sbt 0.9. I expect it to be more difficult to reproduce bugs. It would be helpful to have a mode that generates a diff between successive compilations and records the options passed to scalac. This could be replayed or inspected to try to find the cause.
|
||||
9. Take the webstart support from 0.7 and make it a 0.9 plugin
|
||||
10. Take ownership of the 0.7 installer plugin and make it an independent 0.9 plugin
|
||||
8. There is more aggressive incremental compilation in sbt 0.10. I expect it to be more difficult to reproduce bugs. It would be helpful to have a mode that generates a diff between successive compilations and records the options passed to scalac. This could be replayed or inspected to try to find the cause.
|
||||
9. Take the webstart support from 0.7 and make it a 0.10 plugin
|
||||
10. Take ownership of the 0.7 installer plugin and make it an independent 0.10 plugin
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ Any session settings for the plugin definition project that have not been saved
|
|||
|
||||
### Global plugins
|
||||
|
||||
In sbt 0.7.x, a processor was a way to add new commands to sbt and distribute them to users. A key feature was the ability to have per-user processors so that once declared, it could be used in all projects for that user. In sbt 0.9, plugins and processors are unified. Specifically, a plugin can add commands and plugins can be declared globally for a user.
|
||||
In sbt 0.7.x, a processor was a way to add new commands to sbt and distribute them to users. A key feature was the ability to have per-user processors so that once declared, it could be used in all projects for that user. In sbt 0.10, plugins and processors are unified. Specifically, a plugin can add commands and plugins can be declared globally for a user.
|
||||
|
||||
The `~/.sbt/plugins/` directory is treated as a global plugin definition project. It is a normal sbt project whose classpath is available to all sbt project definitions for that user as described above for per-project plugins.
|
||||
|
||||
|
|
@ -85,7 +85,7 @@ To switch back to the main project:
|
|||
|
||||
### 1d) Project dependency
|
||||
|
||||
This variant shows how to use the external project support in sbt 0.9 to declare a source dependency on a plugin.
|
||||
This variant shows how to use the external project support in sbt 0.10 to declare a source dependency on a plugin.
|
||||
This means that the plugin will be built from source and used on the classpath.
|
||||
|
||||
Edit `project/plugins/project/Build.scala`
|
||||
|
|
|
|||
2
Setup.md
2
Setup.md
|
|
@ -1,4 +1,4 @@
|
|||
[sbt-launch.jar]: http://typesafe.artifactoryonline.com/typesafe/ivy-releases/org.scala-tools.sbt/sbt-launch/0.9.10/sbt-launch.jar
|
||||
[sbt-launch.jar]: http://typesafe.artifactoryonline.com/typesafe/ivy-releases/org.scala-tools.sbt/sbt-launch/0.10.0/sbt-launch.jar
|
||||
[ScalaCheck]: http://code.google.com/p/scalacheck/
|
||||
[specs]: http://code.google.com/p/specs/
|
||||
[ScalaTest]: http://www.artima.com/scalatest/
|
||||
|
|
|
|||
11
Tasks.md
11
Tasks.md
|
|
@ -1,10 +1,13 @@
|
|||
[TaskStreams]: http://harrah.github.com/xsbt/latest/api/sbt/std/TaskStreams.html
|
||||
[Logger]: http://harrah.github.com/xsbt/latest/api/sbt/Logger.html
|
||||
[Incomplete]: https://github.com/harrah/xsbt/latest/api/sbt/Incomplete.html
|
||||
[Result]: https://github.com/harrah/xsbt/latest/api/sbt/Result.html
|
||||
|
||||
# Tasks
|
||||
|
||||
# Introduction
|
||||
|
||||
sbt 0.9 has a new task system that integrates with the new settings system.
|
||||
sbt 0.10 has a new task system that integrates with the new settings system.
|
||||
Both settings and tasks produce values, but there are two major differences between them:
|
||||
|
||||
1. Settings are evaluated at project load time. Tasks are executed on demand, often in response to a command from the user.
|
||||
|
|
@ -212,7 +215,7 @@ intTask <<= intTask.dependsOn(stringTask, sampleTask)
|
|||
|
||||
## Streams: Per-task logging
|
||||
|
||||
New in sbt 0.9 are per-task loggers, which are part of a more general system for task-specific data called Streams. This allows controlling the verbosity of stack traces and logging individually for tasks as well as recalling the last logging for a task. Tasks also have access to their own persisted binary or text data.
|
||||
New in sbt 0.10 are per-task loggers, which are part of a more general system for task-specific data called Streams. This allows controlling the verbosity of stack traces and logging individually for tasks as well as recalling the last logging for a task. Tasks also have access to their own persisted binary or text data.
|
||||
|
||||
To use Streams, `map` or `flatMap` the `streams` task. This is a special task that provides an instance of [TaskStreams] for the defining task. This type provides access to named binary and text streams, named loggers, and a default logger. The default [Logger], which is the most commonly used aspect, is obtained by the `log` method:
|
||||
```scala
|
||||
|
|
@ -287,7 +290,7 @@ It is obvious here that calling intTask() will never result in "finally" being p
|
|||
|
||||
`mapFailure` accepts a function of type `Incomplete => T`, where `T` is a type parameter.
|
||||
In the case of multiple inputs, the function has type `Seq[Incomplete] => T`.
|
||||
[Incomplete](https://github.com/harrah/xsbt/blob/0.9/tasks/Incomplete.scala) is an exception with information about any tasks that caused the failure and any underlying exceptions thrown during task execution.
|
||||
[Incomplete] is an exception with information about any tasks that caused the failure and any underlying exceptions thrown during task execution.
|
||||
The resulting task defined by `mapFailure` fails if its input succeeds and evaluates the provided function if it fails.
|
||||
|
||||
For example:
|
||||
|
|
@ -352,7 +355,7 @@ The following table lists the results of invoking `c-task`, depending on the suc
|
|||
|
||||
`mapR` accepts a function of type `Result[S] => T`, where `S` is the type of the task being mapped and `T` is a type parameter.
|
||||
In the case of multiple inputs, the function has type `(Result[A], Result[B], ...) => T`.
|
||||
[Result](https://github.com/harrah/xsbt/blob/0.9/tasks/Result.scala) has the same structure as `Either[Incomplete, S]` for a task result of type `S`.
|
||||
[Result] has the same structure as `Either[Incomplete, S]` for a task result of type `S`.
|
||||
That is, it has two subtypes:
|
||||
|
||||
* `Inc`, which wraps `Incomplete` in case of failure
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
[web plugin]: https://github.com/siasia/xsbt-web-plugin
|
||||
|
||||
# Triggered Execution
|
||||
|
||||
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.
|
||||
|
|
@ -28,9 +30,7 @@ The following will poll for changes to your source code (main or test) and run `
|
|||
|
||||
## Web Applications
|
||||
|
||||
**Web support not yet implemented in 0.9**
|
||||
|
||||
If you use `jetty-run`, you can automatically build and reload your web application on changes to your source:
|
||||
If you use `jetty-run` from the [web plugin], you can automatically build and reload your web application on changes to your source:
|
||||
|
||||
```scala
|
||||
> jetty-run
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
* Getting Started
|
||||
* [[Setup]] - Getting sbt running on your machine
|
||||
* [[Running]] - Using sbt from the command line
|
||||
* [[Migrating from sbt 0.7.x to 0.9.x]]
|
||||
* [[Migrating from sbt 0.7.x to 0.10.x]]
|
||||
* Usage
|
||||
* [[Triggered Execution]]
|
||||
* [[Cross Build]]
|
||||
|
|
@ -34,8 +34,8 @@
|
|||
* Project Information
|
||||
* [[Credits]]
|
||||
* [[Changes]]
|
||||
* [[Source code|https://github.com/harrah/xsbt/tree/0.9]]
|
||||
* [[License|https://github.com/harrah/xsbt/blob/0.9/LICENSE]]
|
||||
* [[Source code|https://github.com/harrah/xsbt/tree/0.10]]
|
||||
* [[License|https://github.com/harrah/xsbt/blob/0.10/LICENSE]]
|
||||
* [[API Documentation|http://harrah.github.com/xsbt/latest/api/index.html]]
|
||||
* [[SXR Documentation|http://harrah.github.com/xsbt/latest/sxr/index.html]]
|
||||
* [[Opportunities]]
|
||||
Loading…
Reference in New Issue