Thanks, Adam, for the detailed explananation.
Etienne
On 30.11.2010, at 23:29, Adam Murdoch wrote:
>
> On 29/11/2010, at 11:28 AM, Etienne Studer wrote:
>
>> Hi
>>
>> Is it by design that excluding a task with -x on the cmd line behaves
>> differently from disabling a task in the code with task.enabled = false. -x
>> does smart merging, task.enabled = false does not.
>
> They are intended to work differently.
>
> There are 2 points in the Gradle lifecycle that we care about whether a task
> should be executed:
>
> * When we assemble the task graph. The -x option works at this point by
> vetoing tasks being added to the task graph.
>
> * Immediately before the task is to be executed. The enabled flag and the
> onlyIf predicates are applied at this point. The idea is that these are to be
> used if there is some dynamic constraint on the task's execution which cannot
> be determined until all the dependencies of the task have been executed. They
> are not intended to exclude tasks from the graph.
>
> So perhaps we are missing is some way to exclude a task from being added to
> the task graph. Some options:
>
> 1. Add an included flag and an includeOnlyIf { } method, which are evaluated
> when the task graph is assembled.
>
> 2. Move the evaluation of onlyIf { } to task graph assembly time. To check at
> execution time, you would use a task action that throws a
> StopExecutionException.
>
> 3. Make it easier to define conditional dependencies. Then, you exclude a
> task by having nothing depend on it.
>
> 4. Improve plugins so that we need to use 'enabled = false' less often.
>
> 5. Allow the evaluation of onlyIf {} to float, so that it happens as soon as
> possible, but not necessarily when the task graph is assembled. Gradle would
> execute only those dependencies (if any) which are required to figure out if
> the task is required or not. This would fit quite well with the changes being
> proposed in
> http://docs.codehaus.org/display/GRADLE/Gradle+1.0+Build+Configuration+DSL
>
> My preference would be options 3 and 4, and 5 in the longer term.
>
>
> --
> Adam Murdoch
> Gradle Developer
> http://www.gradle.org
> CTO, Gradle Inc. - Gradle Training, Support, Consulting
> http://www.gradle.biz
>
Etienne Studer
Senior Software Developer
Canoo Engineering AG
Kirschgartenstrasse 5
CH-4051 Basel
T +41 61 228 94 44
F +41 61 228 94 49
[email protected]
www.canoo.com
