Docs: last updates to getting started guide for 0.13.0

src/sphinx/Getting-Started/Basic-Def.rst

@@ -11,14 +11,11 @@ Getting Started Guide.
 
 An sbt build definition can contain files ending in `.sbt`, located in
 the base directory, and files ending in `.scala`, located in the
-`project` subdirectory of the base directory.
+`project/` subdirectory the base directory.
 
-You can use either one exclusively, or use both. A good approach is to
-use `.sbt` files for most purposes, and use `.scala` files only to
-contain what can't be done in `.sbt`.
-
-This page discusses `.sbt` files. See :doc:`.scala build definition <Full-Def>` (later in Getting Started) for
-more on `.scala` files and how they relate to `.sbt` files.
+This page discusses `.sbt` files, which are suitable for most cases.
+The `.scala` files are typically used for sharing code across `.sbt` files and for larger build definitions.
+See :doc:`.scala build definition <Full-Def>` (later in Getting Started) for more on `.scala` files.
 
 What is a build definition?
 ---------------------------

src/sphinx/Getting-Started/Custom-Settings.rst

@@ -40,12 +40,9 @@ reload, while a task is re-computed for every "task execution" (every
 time someone types a command at the sbt interactive prompt or in batch
 mode).
 
-Keys may be defined in a `.scala` file (as described in :doc:`.scala build definition <Full-Def>`),
-or in a plugin (as described in
-:doc:`using plugins <Using-Plugins>`). Any `val` found in
-a `Build` object in your `.scala` build definition files, or any
-`val` found in a `Plugin` object from a plugin, will be imported
-automatically into your `.sbt` files.
+Keys may be defined in a `.sbt file <Basic-Def>` file, :doc:`.scala file <Full-Def>`, or in a :doc:`plugin <Using-Plugins>`.
+Any `val` found in a `Build` object in your `.scala` build definition files or any
+`val` found in a `Plugin` object from a plugin will be imported automatically into your `.sbt` files.
 
 Implementing a task
 -------------------

src/sphinx/Getting-Started/Full-Def.rst

@@ -194,24 +194,11 @@ In summary:
 When to use `.scala` files
 ----------------------------
 
-In `.scala` files, you can write any Scala code including `val`, `object`,
-and method definitions.
+In `.scala` files, you can write any Scala code, including top-level classes and objects.
+Also, there are no restrictions on blank lines, since they are standard `.scala` files.
 
-*One recommended approach is to define settings in `.sbt` files, using
-`.scala` files when you need to factor out a `val` or `object` or
-method definition.*
-
-There's one build definition, which is a nested project inside your main
-project. `.sbt` and `.scala` files are compiled together to create
-that single definition.
-
-`.scala` files are also required to define multiple projects in a
-single build. More on that is coming up in :doc:`Multi-Project Builds <Multi-Project>`.
-
-(A disadvantage of using `.sbt` files in a :doc:`multi-project build <Multi-Project>` is that they'll be spread around
-in different directories; for that reason, some people prefer to put
-settings in their `.scala` files if they have sub-projects. This will
-be clearer after you see how :doc:`multi-project builds <Multi-Project>` work.)
+The recommended approach is to define most configuration in `.sbt` files, using
+`.scala` files for task implementations or to share values, such as keys, across `.sbt` files.
 
 The build definition project in interactive mode
 ------------------------------------------------

src/sphinx/Getting-Started/Running.rst

@@ -45,9 +45,9 @@ in quotes. For example,
 
     $ sbt clean compile "testOnly TestA TestB"
 
-In this example, `test-only` has arguments, `TestA` and `TestB`.
+In this example, `testOnly` has arguments, `TestA` and `TestB`.
 The commands will be run in sequence (`clean`, `compile`, then
-`test-only`).
+`testOnly`).
 
 Continuous build and test
 -------------------------

src/sphinx/Getting-Started/Summary.rst

@@ -41,14 +41,13 @@ sbt: The Core Concepts
 -  the per-project axis also supports "entire build" scope.
 -  scopes fall back to or *delegate* to more general scopes.
 -  :doc:`.sbt <Basic-Def>` vs. :doc:`.scala <Full-Def>` build definition
--  put most of your settings in `build.sbt`, but use `.scala` build
-   definition files to :doc:`define multiple subprojects <Multi-Project>`
-   , and to factor out common values, objects, and methods.
+-  put most of your configuration in `build.sbt`, but use `.scala` build
+   definition files for defining classes and larger task implementations.
 -  the build definition is an sbt project in its own right, rooted in
    the `project` directory.
 -  :doc:`Plugins <Using-Plugins>` are extensions to the
    build definition
--  add plugins with the `addSbtPlugin` method in `project/build.sbt`
+-  add plugins with the `addSbtPlugin` method in `project/plugins.sbt`
    (NOT `build.sbt` in the project's base directory).
 
 If any of this leaves you wondering rather than nodding, please ask for

src/sphinx/Getting-Started/Using-Plugins.rst

@@ -81,7 +81,7 @@ Some especially popular plugins are:
 Creating a Plugin
 -----------------
 
-A minimal plugin is a Scala library that is built against the version of Scala that sbt runs, which is currently |scalaVersion|.
+A minimal plugin is a Scala library that is built against the version of Scala for sbt itself, which is currently |scalaVersion|.
 Nothing special needs to be done for this type of plugin.
 It can be published as a normal project and declared in `project/plugins.sbt` like a normal dependency (without `addSbtPlugin`).