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. If not, this
wouldn't be a release blocker. It would be very cool to have a nice
API for this. But it should not change again in 0.7. Let's wait to
hear the Tom's status for the detection code.
(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
