On Jul 28, 2009, at 7:05 AM, Adam Murdoch wrote:
Hans Dockter wrote:
On Jul 21, 2009, at 6:27 AM, Adam Murdoch wrote:
Steve Appling wrote:
I have been trying to make use of the new onlyIf method to
optimize our large build. OnlyIf seemed liked a very useful
approach in the abstract, but is proving to be more of a
challenge in a real project. It was useful for a few tasks (like
jar.onlyIf { compile.didWork || processResources.didWork }), but
not for some of the more expensive ones. The Test task, in
particular, has been frustrating.
I tried the somewhat too simple:
test.onlyIf { compile.didWork || testCompile.didWork ||
processTestResources.didWork }
This does exactly what it says, it only runs the tests if new
code was compiled or the test resources changed and this seemed
great at first glance. When I tried this on our real project,
however, I was disappointed. What this will do is to cause the
test task for a module to be run only once. If it fails and the
developer does not correct it, then the next time the build is
run the test will be skipped. This gives the false impression
that everything is correct when it is not. To be useful, I think
this also needs some type of state information about whether the
tests passed last time, but this is getting more complicated than
I originally envisioned.
A general solution to this problem is going to have to remember
whether a task has completed or failed to execute. It is also
going to have to consider the output artifacts of the task (and do
a better job with the input artifacts). I think it is reasonable
for Gradle to maintain this state, provided we do so in a general-
purpose way.
For example, this is something that the OptimisationHelper could
expose, that the onlyIf clause can make use of if it cares:
test.onlyIf { compile.didWork || ... || !completedSuccessfully }
Why not provide the completedSuccessfully (possibly with a
different name) as a task property? As a first implementation we
could have a file (somewhere in .gradle) for each task being
executed. This file just contains true/false at the moment. False
is returned if the file contains false or the file does not exists.
Thinking about this a bit more, we would have to be able to answer
the question: has task A completed successfully since it's
dependencies last did work?
For example:
1. run gradle test, it completes successfully.
2. change some source.
3. run gradle compile
4. run gradle test
The tests should be run in step 4. However, if we stored true/false,
they would not run. Perhaps timestamps would be a better option.
Good point.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
