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.
(a): If a task gets skipped, we will automatically skip all tasks
where the skipped task is the only one that depends on them.
(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.
(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
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
