2009/4/17 Hans Dockter <[email protected]> > > 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.
Very nice indeed. > > > - Hans > > -- > Hans Dockter > Gradle Project lead > http://www.gradle.org > > > > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
