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. And as a
mechanism to allow different ways of arranging the execution of tasks
which we haven't foreseen.
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.
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.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
