Grade task dependences

build.gradle

/*

Now that we can declare tasks, it's time to think about the relationships
between tasks. For example, in a Java build, we can't JAR up our library
before compiling our sources. We model these relationships by task
dependencies and ordering.

We'll discuss three ways to configure the relationships between tasks:
`dependsOn`, `finalizedBy`, and `mustRunAfter`.

Task A `dependsOn` task B if task A can't do its work without task B having
done its work. To take a familiar example, when you're getting up in the
morning, you can't put on your shoes without putting on your socks first.
Let's declare and configure some tasks to represent this process.

*/

task putOnSocks {
    doLast {
        println "Putting on Socks."
    }
}

task putOnShoes {
    dependsOn "putOnSocks"
    doLast {
        println "Putting on Shoes."
    }
}

/*

One thing to note is that if you run `gradle tasks`, you won't see
`putOnSocks`. That's because Gradle assumes that `putOnSocks` exists only to
help `putOnShoes` do its job. You can still see the `putOnSocks` task by
running `gradle tasks --all`.

Task A is `finalizedBy` task B if every time task A runs, task B should be run
afterwards. To continue our example, every time you eat breakfast, you must
brush your teeth afterwards. Let's create those tasks, and declare the
relationship between them.

*/

task eatBreakfast {
    finalizedBy "brushYourTeeth"
    doLast{
        println "Om nom nom breakfast!"
    }
}

task brushYourTeeth {
    doLast {
        println "Brushie Brushie Brushie."
    }
}

/*

The use case for `mustRunAfter` is slightly less obvious. Say we have a long
running process that's unlikely to fail, like deploying some artifact to a
continuous integration server, and we also have a short running task that is
likely to fail, like running unit tests. Those two tasks don't have any
dependency relationship, but if we're running both, we would really like the
unit tests to run before the integration tests.

To continue our morning routine example, let's consider showering and putting
on a fragrance like perfume or cologne. Putting on a fragrance doesn't require
showering, and showering doesn't require putting on a fragrance, but if we're
going to both take a shower and also put on a fragrance, we should take the
shower first. Let's create those tasks and the relationship between them.

*/

task takeShower {
    doLast {
        println "Taking a shower."
    }
}

task putOnFragrance {
    shouldRunAfter "takeShower"
    doLast{
        println "Smellin' fresh!"
    }
}

/*

Now if we run `gradle putOnFragrance takeShower`, we see that we do the tasks
in the proper order.

Let's check out a few other things we can do with task dependencies. We can
depend on multiple tasks:

*/

task getReady {
    // Remember that when assigning a collection to a property, we need the
    // equals sign
    dependsOn = ["takeShower", "eatBreakfast", "putOnShoes"]
}

/*

Oops, we put on our shoes before taking a shower! Let's put in another
`mustRunAfter` relationship.

*/

putOnShoes.mustRunAfter takeShower

/*

One more advanced thing we can do is look at all the tasks in the project and
decide which ones we want to depend on. Let's make a task called `getEquipped`
that depends on every task that starts with "putOn".

*/

task getEquipped {
    dependsOn tasks.matching{ task -> task.name.startsWith("putOn")}
    doLast {
        println "All geared up!"
    }
}

/*

You don't need to understand all the Groovy and Gradle in that last example
quite yet. We just wanted to show off some of the power of Gradle. This is the
sort of thing that's difficult or impossible hard to do with other build
tools. For more information about tasks, check out this section of the Gradle
user guide for more info:

    https://docs.gradle.org/current/userguide/more_about_tasks.html

*/