Hans Dockter wrote:
On Sep 14, 2008, at 1:01 PM, Adam Murdoch wrote:
Hans Dockter wrote:
On Sep 13, 2008, at 8:51 AM, Adam Murdoch wrote:
It might be interesting to add some DAG mutation methods at some
point. For example, I'd like to be able to request the execution of
a task from another task.
Do you see this as a solution for the doFinally?
Not really, I hadn't really considered that (though it is an
interesting idea). I just wanted it for putting together canned
builds coded up as tasks, eg run 'clean', then 'assemble' with 'test'
disabled.
This is really the 'build type' concept which I described (vaguely) in
another email. I'm not sure of the semantics yet, but basically I want
to code up canned builds which are variations of the build as declared
in the build file.
The DAG is currently passed as a method to TaskAction.execute() and
is also reachable from Task. Should we remove it from
TaskAction.execute()? If we do the above, should we remove it from
Task as well? If not, should we add it to Project and ProjectAction
for consistency?
I was thinking about making the DAG accessible from the project. But
I thought this might be not such a good idea, as the hasTask and
getAllTasks methods only have a meaning at execution time. The fact
that the DAG is a member of the BaseTask is an internal
implementation detail. So the only public way of accessing the DAG
right now is via the argument we pass to the TaskAction. If we
introduce listeners we have to make them of course accessible from
the project (in a way you described above). The question is whether
we should expose 'execution time only' methods via this interface.
I did wonder about this. Even though some information makes sense
only at execution time, it doesn't really make sense to me that you
get at this information via a parameter on a TaskAction. It's not
really something particular to a Task. It's information about the
build as a whole, so it feels to me like something that should hang
off an object that represents the build.
I was thinking of having the methods visible from Project, but have
them throw an exception of some kind when used before the graph had
been assembled.
I don't feel strong about this. An exception would definitely make
sense. We should also throw an exception if dependsOn is called during
execution time.
Or handle it. It's only a problem if the task has already executed or is
currently executing (or introduces a cycle).
One limitation of the current solution is that you can only access
the dag in a task. For example in the Gradle build we access the DAG
in the init task to decide if we attach a timestamp to the version
or nor. Every task now has to depends on init if it wants to use the
version (e.g. userguide creation). This is not nice. See
http://jira.codehaus.org/browse/GRADLE-163. A method for the
taskGraph like beforeGraphExecution would solve this I think.
I think those listeners are great stuff and with a little bit of
work towards embaddibility they will make it very easy to write a
Gradle IDE plugin. Jayson Minard had already a look into writing an
IDE plugin in 0.2. But our design wasn't ready then.
What we would additionally need in the Build class is:
- a method that returns the task map.
- some filtering of the task map based on projectDir and project.
- exposing the taskGraph object to add listeners.
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. We can certainly have the scripts compiled up and classes loaded
ready to evaluate.
I'm not sure if the actual evaluation time is that big a deal, relative
to the total build time. 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.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
