-- Since Kobalt's build files are actual Kotlin files, not only can you leverage auto-completion - to write your build files but the full power of your IDEA is at your fingertips to write - these files in any way you see fit: using expressions, conditionals, classes, extension functions, - constants... The sky is the limit! -
-- Kobalt uses Kotlin's type safe builder pattern to offer a DSL that's extremely similar to Gradle - and minimalistic while allowing you to switch to full Kotlin code whenever necessary. -
-- Here is an example of the auto-completion dialog: -
-
-
-
- And see the following section to get a feel for Kobalt's build file syntax. -
-For example, here is JCommander's entire build file: @@ -133,7 +112,31 @@ val jcommander = project {
This build file also includes a directive to upload your artifacts to Bintray automatically.
-+ Since Kobalt's build files are actual Kotlin files, not only can you leverage auto-completion + to write your build files but the full power of your IDEA is at your fingertips to write + these files in any way you see fit: using expressions, conditionals, classes, extension functions, + constants... The sky is the limit! +
++ Kobalt uses Kotlin's type safe builder pattern to offer a DSL that's extremely similar to Gradle + and minimalistic while allowing you to switch to full Kotlin code whenever necessary. +
++ Here is an example of the auto-completion dialog: +
+
+
+
+ And see the following section to get a feel for Kobalt's build file syntax. +
+ + +Most of Kobalt's core tasks are incremental, which means that if you run them without having changed anything, they will be skipped. The support for incremental tasks is also trivial to add for plug-in developers, which guarantees that your builds with Kobalt will always be as fast as they can be.
diff --git a/plug-in-development/index.html b/plug-in-development/index.html index 7995665..13d014d 100644 --- a/plug-in-development/index.html +++ b/plug-in-development/index.html @@ -436,7 +436,7 @@ Tasks are provided by plug-ins and can be invoked from the command line, e.g.
-@Task(name = "lineCount", description = "Count the lines", runBefore = arrayOf("compile"))
+@Task(name = "lineCount", description = "Count the lines", dependsOn = arrayOf("compile"))
fun lineCount(project: Project): TaskResult {
// ...
return TaskResult()
@@ -452,70 +452,76 @@ The @Task annotation accepts the following attributes:
kobaltw command.
-The difference between runAfter and alwaysRunAfter is subtle but important. runAfter
-is just a declaration of dependency. It's basically the reverse of runBefore but it's useful in case
-you are not the author of the task you want to run before (if you were, you would just use the runBefore
-annotation on it). Since you can't say "a runBefore b" because you don't own task "a",
-you say "b runAfter a".
+ Kobalt defines two different concepts for tasks: dependencies and orderings. And for each of this concept,
+ you can define the relation to go in one direction or the other.
-For example, compileTest is declared as a runAfter for the task compile.
-This means that it doesn't make sense to run compileTest unless compile has run first.
-However, if a user invokes the task compile, they probably don't want to invoke compileTest,
-so a dependency is exactly what we need here: invoking compileTest will trigger compile
-but not the other way around.
+ If your task cannot run until another task has run, you need to declare a dependency. Dependencies cause
+ additional tasks than those requested to be executed. For example, "assemble" depends on "compile", which means that whenever you invoke "assemble", "compile"
+ will be automatically run first. This is a dependency and it is controlled by "dependsOn" and
+ "reverseDependsOn". You can see "reverseDependsOn" as a way to insert your task before an existing task.
-However, there are times where you want to define a task that will always run after a given task.
-For example, you could have a signJarFile task that should always be invoked if someone builds a jar
-file. You don't expect users to invoke that target explicitly, but whenever they invoke the assemble
-target, you want your signJarFile target to be invoked. When you want such a task to always be invoked
-even if the user didn't explicitly request it, you should use alwaysRunAfter.
-Note that there is no alwaysRunBefore annotation since runBefore
-achieves the same functionality.
+ Orderings, controlled by "runBefore" and "runAfter" merely specify an ordering
+ but do not pull new tasks in. This is how you tell Kobalt "In case task X is run, run my task before it
+ (or after)". But if task X doesn't run, your task will not be run either (unless it's explicitly requested
+ by the user).
-Here are a few different scenarios to illustrate how the three attributes work for the task exampleTask:
+Here are a few different scenarios to illustrate how the three attributes work for the task example:
Result of the command ./kobaltw --dryRun compile
Configuration for exampleTask |
+ Configuration for example |
Result | +Note |
| runBefore = "compile" | +dependsOn = "compile" |
-kobalt-line-count:clean -kobalt-line-count:exampleTask -kobalt-line-count:compile+ clean +compile +example+ |
+
+ Make the "example" task depend on "compile".
+ |
+
| reverseDependsOn = "compile" | +
+clean +example +compile+ |
+
+ Insert the "example" task before "compile".
|
|
| runAfter = "compile" |
-kobalt-line-count:clean -kobalt-line-count:compile+ clean +compile |
- ||
| alwaysRunAfter = "compile" |
-kobalt-line-count:clean -kobalt-line-count:compile -kobalt-line-count:exampleTask+ Make "example" run after "compile" but only if it's invoked explicitly.
|
+