Hi,
I have implemented a task optimization functionality that we might put
into 0.8. I have uploaded my branch to: http://github.com/hansd/gradle/tree/optim
A couple of comments:
1.) The task history is now stored in gradle user home with some hash
that relates it to the actual project. The base for the hash is the
path of the root dir. We might have issues if a subproject takes part
in multiple multi-project builds, if the output is sensitive to the
respective multi-project build. The only way I see to solve such a
problem, would be to have multiple output dirs.
2.) Each task has a now doesOutputExists() method which defaults to
false. So far all archive tasks have a custom implementation which
checks for the existence of the archive. The test task also has a
custom implementation which checks for at least one test results file.
I hope that we find a way to automate this in 0.9 by introducing a
generic notion of task output.
3.) So far there are onlyIf implementations only for the test and the
jar task provided by the Java plugin. I will add an onlyIf
modification for the test task when the Groovy plugin is applied
tomorrow. For 0.9 we want to automate the onlyIf statements based on
the information we have on the input arguments of a task.
4.) What about the other tasks? For java compile the Ant javac task
has its own optimization checking for changed files. I'm not sure
about groovyc, I need to check. The Ant Javadoc/Groovydoc tasks do not
check for changed files. To optimize them we would need to check for
changed source files. The same is true for the code quality stuff. I'm
not sure whether I will have time to get this done before 0.8. I would
use Tom's change detection stuff. I haven't had a look at that yet.
For 0.9 I guess the SourceSet's will be a good place for source change
detection. For 0.8 it might be already good enough to distinguish
between no changes/do nothing and do the full thing.
5.) The onlyIf optimization needs to be disabled if any build.gradle
which is part of the multi-project build, the settings.grade or an
init.gradle changes. Therefore a ScriptSource object now has a method
hasChanged which defaults to true. The DefaultScriptCompilerFactory
sets it to false if a script is read from the cache. I'm not very
happy about the latter mechanism. To me this looks like a hint that
the ScriptSource should be responsible for the compilation, instead of
the compile class having a side effect on the state of ScriptSource. I
will think about this in more detail tomorrow.
6.) The GradleInternal class exposes now the settings and the init
script ScriptSource objects. It also provides a convenience method to
check whether any ScriptSource object has changed. To get hold of the
settings object it registers as a BuildListener. I think there should
be a better way. I will think more about this tomorrow.
I'm not completely sure whether we want to push this into 0.8 or not.
Feedback is welcome.
@Steve, John, Mike: Would the above described state of change
detection be helpful for your large enterprise build?
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
