On Sep 17, 2008, at 11:56 AM, Adam Murdoch wrote:
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.
Of course. That makes sense.
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.
There is a new comment on the issue: http://jira.codehaus.org/browse/
GRADLE-66
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
