Hi, I'm just working on the training slides regarding excluding or skipping tasks. A couple of thoughts:
Use-cases: 1.) Whether a task should be executed or not depends on the execution time state (e.g. what other tasks have produced) 2.) You don't want a task to be executed for a particular build run (e.g. to save time, avoid errors). 3.) A plugin you need, adds a task you don't want. Examples: 3a.) The test task of the Java Plugin (This is just for making the point. Yu'd better use the java-base plugin then). 3b.) The jar task of the Java plugin when applied from the War plugin. 1.) is solved by onlyIf 2.) is solved by the -x command line option. 3.) Most of the time the granularity of the plugin might be not appropriate. But considering a growing number of external plugins, this is not always something that can be changed, besides the fact that we want to provide a solution before the release of the next plugin version. So I think we have to embrace this use case. - Current Solution 1: set someTask.enabled = false -- Disadvantage: The -t output and execution output contains this task although it does nothing and should not be used. The depended upon tasks are still executed, if the disabled tasks is in the DAG. -- Disadvantage: Executing the task from the command line does not throw an exception. -- Advantage: The disabling can be easily reversed by setting enabled to true again. -- Alternative approach: someTask.actions = [] // although not (easily) reversable - Current Solution 2: Exclude the task with the taskgraph filter. -- Advantage: The task does not show up in the execution output. The depended upon tasks are also excluded. -- Disadvantage: The task shows still up in -t (that could be easily fixed). -- Disadvantage: It is incovenient or even very hard to reverse. We could make this easier. We could add for example an exclude property to a task. -- Disadvantage: Executing the task from the command line does not throw an exception. This is also something we could fix. - Possible other (to be implemented) solution: Enable a smart remove of a task. You would need to build the DAG to do a smart remove. There can also be a lot of other couplings (e.g. configuration relationships) that is hard to take into account. Although they might result into a runtime exception which might be OK. But there would be a awkward order dependence when you do a remove. Conclusions: - I would like to deprecate the enabled option. - I would like to add some additional behavior to the DSL and the core to make exclusion stronger. - With the future configuration tasks you can also control whether the corresponding configuration task of an excluded tasks should be excluded (e.g. by creating additional dependsOn to make them not excluded.) - We should promote the best practices that plugins (if necessary) should come in two forms. A base plugins that adds the toolkit and the conventions. And a framework plugin that builds on top of that and adds the actual task instances. (like Gradle does with java-base and java). - Hans -- Hans Dockter Founder, Gradle http://www.gradle.org, http://twitter.com/gradleorg CEO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz
