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.
(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.
(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.
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
