Merging AutoPlugin work from "0.13.2" branch

main/src/main/scala/sbt/Defaults.scala

@@ -971,7 +971,7 @@ object Classpaths
 		publishM2 <<= publishTask(publishM2Configuration, deliverLocal)
 	)
 	@deprecated("0.13.2", "This has been split into jvmIvySettings and ivyPublishSettings.")
-	val publishSettings: Seq[Setting[_]] = jvmPublishSettings ++ ivyPublishSettings
+	val publishSettings: Seq[Setting[_]] = ivyPublishSettings ++ jvmPublishSettings
 
 	private[this] def baseGlobalDefaults = Defaults.globalDefaults(Seq(
 		conflictWarning :== ConflictWarning.default("global"),

main/src/main/scala/sbt/Plugins.scala

@@ -36,11 +36,11 @@ Steps for users:
 
 For example, given plugins Web and Javascript (perhaps provided by plugins added with addSbtPlugin),
 
-  <Project>.plugins( Web && Javascript )
+  <Project>.addPlugins( Web && Javascript )
 
 will activate `MyPlugin` defined above and have its settings automatically added.  If the user instead defines
 
-  <Project>.plugins( Web && Javascript && !MyPlugin)
+  <Project>.addPlugins( Web && Javascript ).disablePlugins(MyPlugin)
 
 then the `MyPlugin` settings (and anything that activates only when `MyPlugin` is activated) will not be added.
 */
@@ -186,7 +186,7 @@ object Plugins
 			if(removed.isEmpty) Empty else And(removed)
 	}
 
-	/** Defines a clause for `ap` such that the [[AutPlugin]] provided by `ap` is the head and the selector for `ap` is the body. */
+	/** Defines a clause for `ap` such that the [[AutoPlugin]] provided by `ap` is the head and the selector for `ap` is the body. */
 	private[sbt] def asClause(ap: AutoPlugin): Clause =
 		Clause( convert(ap.select), Set(Atom(ap.label)) )
 

main/src/main/scala/sbt/Project.scala

@@ -138,7 +138,7 @@ sealed trait Project extends ProjectDefinition[ProjectReference]
 
 	/** Sets the [[AutoPlugin]]s of this project.
 	A [[AutoPlugin]] is a common label that is used by plugins to determine what settings, if any, to add to a project. */
-	def addPlugins(ns: AutoPlugin*): Project = setPlugins(Plugins.and(plugins, Plugins.And(ns.toList)))
+	def addPlugins(ns: Plugins*): Project = setPlugins(ns.foldLeft(plugins)(Plugins.and))
 
 	/** Disable the given plugins on this project. */
 	def disablePlugins(ps: AutoPlugin*): Project =

sbt/src/sbt-test/project/default-settings/build.sbt

@@ -0,0 +1,8 @@
+
+val root = Project("root", file("."), settings=Defaults.defaultSettings)
+
+
+TaskKey[Unit]("checkArtifacts", "test") := {
+	val arts = packagedArtifacts.value
+	assert(!arts.isEmpty, "Packaged artifacts must not be empty!")
+}

sbt/src/sbt-test/project/default-settings/test

@@ -0,0 +1 @@
+> checkArtifacts

src/sphinx/Architecture/Core-Principles.rst

@@ -60,11 +60,66 @@ the AttributeMap, we first need to construct one of these keys.  Let's look at t
 Now that there's a definition of what build state is, there needs to be a way to dynamically construct it.  In sbt, this is
 done through the ``Setting[_]`` sequence.
 
-Introduction to Settings
-========================
+Settings Architecture
+=====================
 
-TODO - Discuss ``Setting[_]``
+A Setting represents the means of constructing the value of one particular ``AttributeKey[_]`` in the ``AttributeMap`` of build state.  A setting consists of two pieces:
 
-TODO - Transition into ``Task[_]``
+1. The ``AttributeKey[T]`` where the value of the setting should be assigned.
+2. An ``Initialize[T]`` object which is able to construct the value for this setting.
 
-TODO - Transition into ``InputTask[_]``
+Sbt's initialization time is basically just taking a sequence of these ``Setting[_]`` objects and running their initialization objects and then storing the value into the ``AttributeMap``.   This means overwriting an exisitng value at a key is as easy as appending a
+``Setting[_]`` to the end of the sequence which does so.
+
+Where it gets interesting is that ``Initialize[T]`` can depend on other ``AttributeKey[_]``s in the build state.  Each ``Initialize[_]``
+can pull values from any ``AttributeKey[_]`` in the build state's ``AttributeMap`` to compute its value.  Sbt ensures a few things
+when it comes to ``Initialize[_]`` dependencies:
+
+1. There can be no circular dependencies
+2. If one ``Initialize[_]`` depends on another ``Initialize[_]`` key, then *all* associated ``Initialize[_]`` blocks for that key must
+   have run before we load the value.
+
+Let's look at what gets stored for the setting ::
+
+  normalizedName := normalize(name.value)
+
+
+
+.. Note: This image comes from a google drawing: https://docs.google.com/a/typesafe.com/drawings/d/1hvE89XVrQiXdSBsgaQgQGTmcO44EBZPg4_0WxKXU7Pw/edit
+.. Feel free to request access to modify as appropriate.
+
+.. image:: overview-setting-example.png
+
+
+Here, a ``Setting[_]`` is constructed that understands it depends on the value in the ``name`` AttributeKey.  Its initialize block first grabs the value of the ``name`` key, then runs the function normalize on it to compute its value.
+
+This represents the core mechanism of how to construct sbt's build state.  Conceptually, at some point we have a graph of dependencies
+and initialization functions which we can use to construct the first build state.   Once this is completed, we can then start to process
+user requests.
+
+
+
+Task Architecture
+=================
+
+The next layer in sbt is around these user request, or tasks.   When a user configures a build, they are defining a set of repeatable
+tasks that they can run on their project.  Things like ``compile`` or ``test``.   These tasks *also* have a dependency graph, where
+e.g. the ``test`` task requires that ``compile`` has run before it can successfully execute.
+
+Sbt's defines a class ``Task[T]``.  The ``T`` type parameter represents the type of data returned by a task.  Remember the tenets of
+sbt?  "All things have types" and "Dependencies are explicit" both hold true for tasks.   Sbt promotes a style of task dependencies that
+is closer to functional programming:  Return data for your users rather than using shared mutable state.
+
+Most build tools communciate over the filesystem, and indeed sbt, by necessity, does some of this.  However, for stable parallelization it is far better to keep tasks isolated on the filesystem and communicate directly through types.
+
+Similarly to how a ``Setting[_]`` stores both dependencies and an initialization function, a ``Task[_]`` stores both its 
+``Task[_]``dependencies and its behavior (a function).  
+
+
+
+
+TODO - More on ``Task[_]``
+
+TODO - Transition into ``InputTask[_]``, rehash Command
+
+TODO - Tansition into Scope.

src/sphinx/Community/Changes.rst

@@ -2,6 +2,33 @@
 Changes
 =======
 
+0.13.1 to 0.13.2
+~~~~~~~~~~~~~~~~
+- Improved the control over included settings in ``Addsettings``.  Can now control when settings in ``project/*.scala`` files are included.
+- Adding new ``AutoPlugin`` feature, and associated ``plugins`` command.
+- Adding new name-hashing feature to incremental compiler.   Alters how scala dependencies are tracked, reducing number of recompiles necessary.
+- Added the ability to launch servers via the sbt-launcher.
+- Added ``.previous`` feature on tasks which can load the pervious value.
+- Added an ``all`` command which can run more than tasks in parallel.
+- Exposed the 'overwrite' flags from ivy.  Added warning if overwriting a release version.
+- Improve the error message when credentials are not found in Ivy.
+- Improve task macros to handle more scala constructs.
+- Fix ``last`` and ``export`` tasks to read from the correct stream.
+- Fix issue where ivy's ``.+`` dependency ranges were not correctly translated to maven.
+- Override security manager to ignore file permissions (performance issue)
+- 2.11 compatibility fixes
+- Launcher can now handle ivy's ``.+`` revisions.
+- SessionSettings now correctly overwrite existing settings.
+- Adding a simple Logic system for inclusionary/dependency logic of plugins.
+- Improve build hooks for ``LoggerReporter`` and ``TaskProgress``.
+- Serialize incremental compiler analysis into text-file format.
+- Issue a warning when generating Paths and separate already exists in the path.
+- Migrate to Ivy 2.3.0-final.
+- Docs: Use bintray as default repository host
+- Docs: improved docs on test groups.
+- Docs: updated documentation on the Launcher.
+- Docs: started architecture document.
+
 0.13.0 to 0.13.1
 ~~~~~~~~~~~~~~~~