John Murph wrote:
For our TeamCity-Gradle plugin to report tests correctly, we need to
have a way register a test listener. I want to talk about the test
listener later, but right now I want to talk about how one registers a
listener and how Gradle deals with that.
Gradle.java now has a method called addBuildListener(). Adam had
mentioned the idea of an addListener() method that could take any kind
of listener. I would like to replace addBuildListener() with this
method, and register the listener on a ListenerManager object. Then,
any code in Gradle that wants to call back to a listener would go to
the ListenerManager and ask for listeners that implement some
interface. This would provide "one-stop shopping" for all listener's
in Gradle. The DefaultGradleFactory could allocate of ListenerManager
and inject it into each object in Gradle that needs it. The only
issue I see is that sometimes one want's a different listener to be
provided for different times. In that case, I wonder if the
ListenerManager could support ListenerFactory objects that could
create new listeners when desired. I haven't thought that through,
though (wow, that's a confusing sentence).
Thoughts?
I like this idea in general. It would give us a single API behind which
we can deal with cross-cutting event handling things like logging, error
handling and reporting, closure coercion, and concurrency. Later, it
could even deal with remoting - broadcasting and receiving events from
forked and remote Gradle processes.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
