luke
/
sbt
mirror of https://github.com/sbt/sbt.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update the one use case we wanted to make less confusing (and perhaps failed?)

Josh Suereth 2014-03-11 07:38:00 -07:00
parent 1173f87415
commit 02e5228323
1 changed files with 41 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

64
User-Stories:-Project-Natures---AutoPlugins.md → User-Stories:-AutoPlugins.md

@ -85,27 +85,6 @@ error: publishSigned is not defined on project 'root'.
* sbt.plugins.IvyModule * sbt.plugins.IvyModule
``` ```
## User Story: User wants to ensure plugin XYZ has its settings loaded last
User adds the following to their `build.sbt`:
```scala
import AddSettings._
val autoPluginsExceptXYZ = autoPlugins(_ != XYZ)
val enableXYZ = autoPlugins(_ == XYZ)
val important = project.autoSettings(autoPluginsExceptXYZ, enableXYZ, projectSettings, defaultSbtFiles, userSettings)
```
This would ensure the following setting order:
1. All auto plugins enabled for the project except the XYZ plugin
2. The XYZ plugin specficially
3. The settings configured via Build.scala files directly on project instances
4. Any .sbt files found in the baseDirectory of the build.
5. Any settings found in .sbt files of the User's sbt home (`~/.sbt/0.13`)
## User Story: user wants to create a C++ workflow that does not include the Java workflow ## User Story: user wants to create a C++ workflow that does not include the Java workflow
1. User creates a 'root' plugin representing the core C++ features: 1. User creates a 'root' plugin representing the core C++ features:
@ -121,5 +100,44 @@ object CppPlugin extends RootPlugin {
```scala ```scala
def cppProject(name: String, dir: File): Project = def cppProject(name: String, dir: File): Project =
Project(name,file).disablePlugin(plugins.JvmModule).addPlugins(CppPlugin) Project(name,file).disablePlugins(plugins.JvmModule).addPlugins(CppPlugin)
``` ```
## User Story: User wants to ensure the plugins contributing tasks can have users control the order.
Currently the order of plugin defined in `project/plugins.sbt` will be respected, except that plugins
which depend on other plugins will have their settings added after their dependencies.
In addition, you can use the following pattern:
We have a pipeline of tasks to perform in an order:
```scala
case class PipelineStage(priority: Int, task: Task[Unit])
object PipelinerPlugin extends RootPlugin {
val rawPipeline = settingKey[Seq[PipelineStage]]
val pipeline = taskKey[Unit]
override val projectSettings = Seq(
rawPipeline := Nil,
pipeline := (Def.taskDyn {
rawPipeline.value.sortBy(_.priority).map(_.task).join
}).value
)
}
object PipelineStageExamplePlugin extends AutoPlugin {
val stageExamplePriority = settingKey[Int]("my priority")
val stageExampleAction = taskKey[Unit]("my task to do stuff")
def select = PipelinerPlugin
override val projectSettings = Seq(
stageExamplePriority := 1,
stageExampleAction := println("THIS is an example stage")
rawPipeline += stageExamplePriority.value -> stageExampleAction.toTask.value
)
}
```