From 50f74bf625d2bb012c845654bb6830cd93d0fff4 Mon Sep 17 00:00:00 2001 From: Havoc Pennington Date: Tue, 18 Oct 2011 16:57:18 -0400 Subject: [PATCH] a variety of minor Getting Started edits --- .../Getting-Started-Custom-Settings.md | 2 +- Getting-Started/Getting-Started-Full-Def.md | 2 +- .../Getting-Started-Multi-Project.md | 2 +- Getting-Started/Getting-Started-Summary.md | 15 ++++++++------- .../Getting-Started-Using-Plugins.md | 18 ++++++++++-------- 5 files changed, 21 insertions(+), 18 deletions(-) diff --git a/Getting-Started/Getting-Started-Custom-Settings.md b/Getting-Started/Getting-Started-Custom-Settings.md index 1920800..d5b6674 100644 --- a/Getting-Started/Getting-Started-Custom-Settings.md +++ b/Getting-Started/Getting-Started-Custom-Settings.md @@ -51,7 +51,7 @@ Keys may be defined in a `.scala` file (as described in Once you've defined a key, you'll need to use it in some task. You could be defining your own task, or you could be planning to redefine an existing task. Either way looks the same; if the task has no dependencies on other -settings or tasks, use `:=` to associate a function with the task key: +settings or tasks, use `:=` to associate some code with the task key: ```scala sampleStringTask := System.getProperty("user.home) diff --git a/Getting-Started/Getting-Started-Full-Def.md b/Getting-Started/Getting-Started-Full-Def.md index 6100cc7..ffe0097 100644 --- a/Getting-Started/Getting-Started-Full-Def.md +++ b/Getting-Started/Getting-Started-Full-Def.md @@ -258,7 +258,7 @@ this order: - Settings from `.sbt` files in the project. - Build definition projects (i.e. projects inside `project`) have settings from global plugins (`~/.sbt/plugins`) added. - [[using plugins|Getting Started Using Plugins]] explains this + [[Using plugins|Getting Started Using Plugins]] explains this more. Later settings override earlier ones. The entire list of settings forms the diff --git a/Getting-Started/Getting-Started-Multi-Project.md b/Getting-Started/Getting-Started-Multi-Project.md index 06b5b42..6270072 100644 --- a/Getting-Started/Getting-Started-Multi-Project.md +++ b/Getting-Started/Getting-Started-Multi-Project.md @@ -142,7 +142,7 @@ To depend on multiple projects, use multiple arguments to `dependsOn`, like `foo dependsOn(bar)` means that the `Compile` configuration in `foo` depends on the `Compile` configuration in `bar`. You could write this explicitly as -`dependsOn(bar % "compile->compile"`. +`dependsOn(bar % "compile->compile)"`. The `->` in `"compile->compile"` means "depends on" so `"test->compile"` means the `Test` configuration in `foo` would depend on the `Compile` diff --git a/Getting-Started/Getting-Started-Summary.md b/Getting-Started/Getting-Started-Summary.md index 73a66e5..e838b22 100644 --- a/Getting-Started/Getting-Started-Summary.md +++ b/Getting-Started/Getting-Started-Summary.md @@ -27,19 +27,20 @@ to know. transforms sbt's collection of key-value pairs into a new collection. It doesn't change anything in-place. - each setting has a value of a particular type, determined by the key. - - _tasks_ are special settings where the computation to produce the key's - value will be re-run each time you kick off a task. Non-tasks compute the - value once and cache it. + - _tasks_ are special settings where the computation to produce + the key's value will be re-run each time you kick off a + task. Non-tasks compute the value once, when first loading the build + definition. - [[Scopes|Getting Started Scopes]] - each key may have multiple values, in distinct scopes. - scoping may use three axes: configuration, project, and task. - - a configuration is a kind of build, such as the main one (`Compile`) or - the test one (`Test`). - scoping allows you to have different behaviors per-project, per-task, or per-configuration. + - a configuration is a kind of build, such as the main one (`Compile`) or + the test one (`Test`). - the per-project axis also supports "entire build" scope. - - scopes "fall back to" or delegate to more general scopes. - - `.sbt` vs. [[.scala|Getting Started Full Def]] build definition + - scopes fall back to or _delegate_ to more general scopes. + - [[.sbt|Getting Started Basic Def]] vs. [[.scala|Getting Started Full Def]] build definition - put most of your settings in `build.sbt`, but use `.scala` build definition files to [[define multiple subprojects|Getting Started Multi-Project]], and to factor out diff --git a/Getting-Started/Getting-Started-Using-Plugins.md b/Getting-Started/Getting-Started-Using-Plugins.md index 60dfad4..6100b12 100644 --- a/Getting-Started/Getting-Started-Using-Plugins.md +++ b/Getting-Started/Getting-Started-Using-Plugins.md @@ -129,7 +129,7 @@ Some people like to list plugin dependencies (for a project `hello`) in `hello/project/plugins.sbt` to avoid confusion with `hello/build.sbt`. sbt does not care what `.sbt` files are called, so both `build.sbt` and `project/plugins.sbt` are conventions. sbt _does_ of course care where -the sbt files are located. `hello/*.sbt` would contain dependencies for +the sbt files are _located_. `hello/*.sbt` would contain dependencies for `hello` and `hello/project/*.sbt` would contain dependencies for `hello`'s build definition. @@ -143,8 +143,8 @@ However, jars intended for use as sbt plugins can do more. If you download a plugin jar ([here's one for sbteclipse](http://repo.typesafe.com/typesafe/ivy-releases/com.typesafe.sbteclipse/sbteclipse/scala_2.9.1/sbt_0.11.0/1.4.0/jars/sbteclipse.jar)) -and unpack it with `jar xf`, you'll see that it contains a file `sbt/sbt.plugins`. In `sbt/sbt.plugins` -there's something like this: +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: ```text com.typesafe.sbteclipse.SbtEclipsePlugin @@ -200,11 +200,13 @@ settings in `myPluginSettings` to the project. ## Creating a plugin -After reading this far, you pretty much know how to _create_ an sbt plugin -as well. There's one trick to know; set `sbtPlugin := true` in `build.sbt`. -If `sbtPlugin` is true, the project will scan for instances of `Plugin`, -and list them in `sbt/sbt.plugins`. `sbtPlugin := true` also adds sbt to the -project's classpath, so you can use sbt APIs to implement your plugin. +After reading this far, you pretty much know how to _create_ an +sbt plugin as well. There's one trick to know; set `sbtPlugin := +true` in `build.sbt`. If `sbtPlugin` is true, the project will +scan its compiled classes for instances of `Plugin`, and list them +in `sbt/sbt.plugins` when it packages a jar. `sbtPlugin := true` +also adds sbt to the project's classpath, so you can use sbt APIs +to implement your plugin. Learn more about creating a plugin at [[Plugins]] and [[Plugins Best Practices]].