On Sep 13, 2008, at 8:51 AM, Adam Murdoch wrote:
Hi,
I'm looking at adding a public interface for DAG in
org.gradle.api.**, so that it can be documented (and grown). I have
some questions about which DAG methods we want to make public, and
how build files should get at it.
This is important. I have been slack in regard to this.
At this stage, the only methods on DAG which look public to me are:
boolean hasTask(path)
Set<Task> getAllTasks()
I'd like to add some events as well, so that one can listen for the
start and end of execution of a task. I would start with a
TaskExecutionListener interface, and possibly add Closure based
convenience methods later. For example:
interface TaskExecutionListener {
void beforeExecute(Task task)
void afterExecute(Task task)
}
And later, something like
taskGraph.beforeTask { task -> do something }
taskGraph.afterTask { task -> do something }
Our future IDE's will happily use this to start and stop a rolling
wheel for a task :)
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?
As far as access from build files goes, I think we are missing a
good place to hang this from. It would make sense to attach the DAG
to the object which represents the build execution as a whole, but
we don't really have such a concept. Settings plays this role for
the initialisation phase. Build is possibly the right place, but it
lacks a public api, and build files can't access it.
I think we should add an interface to the public api which wraps up
the whole build execution, called something like GradleInstance or
Build. It would be reachable from Project, using, for example,
Project.getGradleInstance()
This interface would have methods something like:
getTaskExecutionGraph()
getRootProject()
addBuildListener(BuildListener)
I like this.
Some other things that could live here are gradle version, gradle
home, user home, and methods for executing a new build.
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.
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.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
