On 02/09/2010, at 6:30 AM, Hans Dockter wrote: > 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.
-- Disadvantage: It uses an internal API. > Current solution 3: Remove any dependencies on the task. Similar to 2 above. > - 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. Another possible future solution is to make it less likely that a plugin adds an unwanted task. For example, say we introduce the concept of a language plugin, that is, one which adds some jvm based language capability to a project. It might implement Plugin<SourceSet> (rather than Plugin<Project>) and Gradle would take care of applying it to each source set in the project. Then, Gradle can synthesise the base and framework plugins from this automatically, without any extra effort by the plugin author. That is, we should introduce abstractions to make plugin authoring easier, and which also happen to naturally lead to no unnecessary tasks being added. This feels like a better direction to head than trying to solve the exclusion problem, at least in the short term. I think we will have to tackle it eventually, but I think that should wait until we've got a better model for how and when things can be configured. -- Adam Murdoch Gradle Developer http://www.gradle.org CTO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz
