2009/5/11 Hans Dockter <[email protected]>
>
> On May 11, 2009, at 2:57 AM, Steve Appling wrote:
>
>
>>
>> Hans Dockter wrote:
>>
>>> On May 10, 2009, at 5:04 AM, Steve Appling wrote:
>>>
>>>>
>>>>
>>>> Adam Murdoch wrote:
>>>>
>>>>> Steve Appling wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Tom Eyckmans wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2009/5/6 Adam Murdoch <[email protected] <mailto:
>>>>>>> [email protected]>>
>>>>>>>
>>>>>>> <clip>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I'm curious, how we will make this available to tasks?
>>>>>>>
>>>>>>> You'd implement a ChangeProcessor that gets notified of what has
>>>>>>> changed, depending how the task works you can just keep a list of the
>>>>>>> files
>>>>>>> / directories that have changed and execute the function of the task on
>>>>>>> the
>>>>>>> list or execute the function of the task in the ChangeProcessor methods.
>>>>>>>
>>>>>>> Currently the change detection always scans for all files /
>>>>>>> directories that have changed, this is not always needed so I'll add
>>>>>>> mulitple old / new state comparison strategies. So you can have only one
>>>>>>> event if the directory has changed in some way or for every file /
>>>>>>> directory
>>>>>>> that has changed.
>>>>>>>
>>>>>>>
>>>>>> When I was experimenting with Tom's change detection, I added a
>>>>>> dependsOnDir method to Task that used his ChangeProcessor. If nothing in
>>>>>> the dir changed, it would throw a StopExecutionException. This seemed to
>>>>>> work well for customizing some simple user defined tasks.
>>>>>>
>>>>> This is a good idea - it's simple, but is probably sufficient for 90%
>>>>> of custom tasks.
>>>>> I'm not sure about the method name - do we want to reuse 'dependsOn' or
>>>>> use a different term?
>>>>> Adam
>>>>>
>>>> That is a good point, Adam. This is very different from the other
>>>> dependencies, in some ways this is the opposite (stopping tasks instead of
>>>> adding more to the DAG). I think there may be a range of these user
>>>> specified optimizations. How about this instead:
>>>>
>>>> Task gets a new method, onlyIf that takes a closure. The closure is run
>>>> before any actions and is expected to return a boolean. If the boolean is
>>>> true, then the task continues executing normally, if it returns false, the
>>>> task is stops execution, but logs an appropriate lifecycle message "skipped
>>>> (optimized)".
>>>>
>>>> The onlyIf closure runs with a delegate of a new class, an
>>>> OptimizationHelper, that has some of the helper methods for various checks
>>>> like Tom's change detection. This could look like:
>>>>
>>>> myTask.onlyIf {
>>>> dirChanged(file 'src/main/java')
>>>> }
>>>>
>>>> or
>>>>
>>>> myTask.onlyIf { !file('build/someresult').exists() }
>>>>
>>>>
>>>> This seems very simple. If anyone likes this, I can make a git branch
>>>> that would support this.
>>>>
>>> I like the idea. It might be implemented in the context of the skipping
>>> refactoring planned for 0.7:
>>> Right now we have enabled true/false, we have skip properties and we have
>>> StopExecutionException to deal with skipping.
>>> For 0.7 we want to have (a) smart skipping, (b) a new command line syntax
>>> and (c) an improved api for skipping.
>>>
>>
>> Is Tom's change detection intended to be a part of 0.6? If so, then do
>> you intend to have any API to use it in 0.6 other than implementing a
>> ChangeProcessor, creating a DirectoryStateChangeDetecter from the factory
>> and registering the ChangeProcessor with it? This seems a little involved
>> for normal use. I thought the onlyIf concept might be a simple way to
>> provide a hook for this.
>>
>
> We really would like to get 0.6 out soon (preferably at the end of this
> week). I don't know how far Tom's change detection stuff is. It is intended
> to be part of 0.6 if it is ready in time.
I think it works, but I need to add some more unit tests for the more
difficult stuff, so I might refactor some stuff while writing the unit
tests. But I think the test class detection stuff has priority over this so
I'll focus on this first for 0.6.
> If not, this wouldn't be a release blocker. It would be very cool to have a
> nice API for this.
I like the proposed onlyIf idea but I think that will not make it in 0.6
because only the base change detection logic is nearing completion.
> But it should not change again in 0.7. Let's wait to hear the Tom's status
> for the detection code.
Totally agree.
>
>
>
>>
>> (a): If a task gets skipped, we will automatically skip all tasks where
>>> the skipped task is the only one that depends on them.
>>>
>>
>> I think this would be a great improvement for 0.7.
>>
>> (b): With the new command line syntax (e.g. -test instead of -Dskip.test)
>>> we might get rid of the notion of skip properties altogether. In particular
>>> as (a) will also solve a subset of the problems where you currently use skip
>>> properties.
>>>
>>
>> Although I haven't ever really liked the concept of skip properties (seems
>> like you could get by with just the task name), I still think that the idea
>> of specifying tasks to skip on the command line may be useful. Although the
>> primary use is to manually optimize (which might not be needed after 0.7)
>> there are still sometimes that only you will know the steps you want
>> skipped. For example, when making gradle's explodedDist, I often want to
>> skip the user guide tasks, regardless of whether they really need to be
>> built. For what I am doing right then, I just don't want them generated.
>>
>
> The new command line syntax will preserve this option. But instead of
> saying 'gradle -Dskip.test libs' you will say something like 'gradle -test
> libs'.
>
>
>>
>> (c): I like the onlyIf idea. I'm wondering if onlyIf can even used to
>>> replace enabled/disabled. (onlyIf { false }). Together with (b) that might
>>> simplify the API in a very nice way. Another thing I'm wondering is, whether
>>> onlyIf should follow the specification pattern (
>>> http://en.wikipedia.org/wiki/Specification_pattern).
>>> Right now skipping a task means not executing its actions. I think a
>>> nicer solution might be to exclude the task from the DAG. In this case we
>>> might also change the terminology from 'skipping a task' to 'excluding a
>>> task'. Excluding would make it easier to follow and work with the execution
>>> of a build. For example when looking at the console output or when working
>>> with the dependency graph.
>>> As an alternative a StopExecutionException would still be available (no
>>> smart skipping, no exclusion from the graph).
>>> Would it makes sense to provide a skipping API also to actions?
>>> - Hans
>>>
>>
>>
>> I think that there are certainly use cases to both exclude a task from the
>> DAG at configuration time or to stop it closer to execution time. Since
>> checking for changes in the directory is relatively expensive, I didn't find
>> it useful to do that at configuration time. I wanted those checks to only
>> execute if the task actually made it into the DAG.
>>
>
> I see your point. As Adam has also pointed out. We have two use cases. One
> is skipping at runtime and the other is excluding at configuration time.
>
> - Hans
>
> --
> Hans Dockter
> Gradle Project lead
> http://www.gradle.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
