On Apr 17, 2009, at 1:13 AM, Adam Murdoch wrote:
Hi,
I'm not entirely happy with some of the semantics and API for our
events, and I'd like to tidy this up before 0.6. In trunk, we have:
* Project evaluation events
- You use a ProjectEvaluationListener which you add to a Project
- Fires beforeEvaluate(project) and afterEvaluate(project) events
- afterEvaluate() is not fired when project evaluation fails
* Task execution events
- You use a TaskExecutionListener which you add to a TaskGraph
- Fires beforeExecute(task) and afterExecute(task, exception) events
- afterExecute() is fired whether the task succeeds or fails.
Some things I don't like about this:
- The task and project 'after' events have different semantics
regarding when they are/are not fired
- Some times you want the 'after' event to be fired regardless of
success or failure, such as when you are doing some custom logging,
or profiling, or building a UI.
- Some times you want the 'after' event to be fired only on success,
such as when you are doing some additional configuration at the end
of project evaluation
- Often you are only interested in the 'after' event
What I'd like to change:
1. Change ProjectEvaluationListener.afterEvaluate() to have the same
semantics as TaskEvaluationListener.afterExecute()
2. Move the use of ProjectEvaluationListener from Project to Build.
3. Use ProjectAction as another notification mechanism for the
project evaluation events. That is, add
Project.beforeEvaluate(ProjectAction)
Project.afterEvaluate(ProjectAction)
The later would only be fired on successful evaluation.
I like all those proposed changes.
* Task creation event
Currently you use a TaskLifecycleListener which you add to a
Project. It has a single taskAdded() event
One problem with this approach is that often you want to do exactly
the same stuff to both existing tasks and new tasks, and it's a
little odd to be using a listener for applying an action to existing
tasks.
I was thinking about use cases for such scenarios. One common use
case, where you usually want to have 'after' configuration is when the
parent project adds tasks to the subprojects and a particular
subproject adds a specific plugin. So I think 'after' configuration
should be the default. We might run into use cases where 'after'
configuration is not wanted or where any plugin configuration of tasks
is not wanted. But let's wait and see. Any configuration can be
overwritten, so we don't lock anyone in with such a default.
So, I'd like to do away with TaskLifecycleListener and replace it
with TaskAction. That is, add
Project.whenTaskAdded(TaskAction)
Then, we can (later) add a method like Project.allTasks(TaskAction)
which can be passed exactly the same action as the listener method.
Thoughts?
Very cool.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
