Hans Dockter wrote:
I was thinking of adding an accessor to Build to get at the
GradleInstance interface (or whatever it is called), so that the
same stuff is available to the thing embedding Gradle as to the
build files. Which I think also includes all the stuff above. We
should perhaps split Build.run() into an initialisation method and
an execution method, so that a plugin could load up the settings
once, do stuff with the GradleInstance, then run tasks a bunch of
times.
This kind of embedded usage is already of interest. For example we
could provide a Gradle UI console then. By using this console you
would avoid the constant startup time penalty of Groovy. An
interesting question is whether you can reuse a evaluated project
tree. It is possible to modify this tree at execution time (although
probably rather unlikely). If this happens the tree can't be reused.
Hmm, good point. Strictly speaking we can't even reuse the settings
object.
Why?
It depends on the timeframe of the reuse. Strictly speaking, we
shouldn't reuse if the settings script depends on something
environmental that is likely to have changed since we evaluated the
script. For example, if the script includes all projects in a directory
and one is added or removed. Or, if it declares a dependency on
'latest.integration' of some custom plugin and a new version becomes
available.
The question is whether we care about such use cases in a Gradle UI. For
a long running UI such as an ide plugin, I think we do. Though, again, I
don't think it's really a bit hit to re-evaluate the settings given the
script has been compiled and cached.
I'm not sure if the actual evaluation time is that big a deal,
relative to the total build time.
In most cases not. In particular as I'm pretty sure that we could
still do significant performance tuning for this evaluation. The only
big performance issue I would like to resolve soon is that the build
source jar is not cached.
Yes, a good idea.
I'm more interested in gradle not building things that haven't
changed since last time I ran the build, and for robustly detecting
things that have changed, so that I don't have to do a clean before I
build.
This would definitely be a real time saver.
What do you think about this issue in this context?
http://jira.codehaus.org/browse/GRADLE-66
I think having a reliable compile task would be excellent.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
