A common use case in Gradle is that you want to have different
variations of task behavior. Our goal is in general to avoid the use
of multiple actions per task to achieve this. In any case, let's look
at an example for variations: You want a test task that runs with and
without coverage. This variation does often not affect the behavior of
the executed task but rather the wiring. For example after a coverage
plugin is applied, the test task depends on instrumentation and is
finalized by the coverage report generation (finalizer is a not yet
implemented concept). Or you might have two variations of an integTest
task. One is running just the test, the other is starting and shutting
down Jetty.
One approach would be to use marker tasks that depend on the actual
task. For example a task integTestWithJetty that depends on Jetty. The
execution of integTestWithJetty would trigger a different wiring of
the the integTest task: runJetty < integTest < stopJetty <
integTestAll. You could play the same game for a test and
testNoCoverage task. It does not feel fully correct to use marker
tasks like this. To have both integTest and integTestAll in the output
feels strange. Those are not lifecycle tasks rather variations of test
and integTest. What about introducing the concept of a task variation?
Something like:
task integTest(type: Test) {
variation {
integTestAll {
dependsOn jettyRun
finalizedBy jettyStop
}
}
}
or
task integTest(type: Test) {
variation {
all {
dependsOn jettyRun
finalizedBy jettyStop
}
}
}
They could be executed either as integTestAll or integTest --all. They
would have the same actions as the actual tasks. They just differ in
the wiring.
Thoughts?
Hans
The variation would always have no
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
