Mike wrote:
We're working on both an Idea and a TeamCity plugin for running gradle. One of
the complexities we're having is getting runtime information back from gradle
while executing. While we can get the information we need, it requires doing
some work that could be simplified. Adding a single 'Execution Listener'
(similar in spirit to the AntBuilderListener) that provides the following would
not only aid our development, but help future gradle plugins. I propose a
single Execution Listener interface made up of the following:
- All the information provided by BuildListener.
- All the information provided by TaskExecutionListener
- Easy access to the logged information (with the order of callbacks easily
associated with the above callbacks).
Are you proposing that ExecutionListener extends BuildListener,
TaskExecutionListener, etc? Or that we replace them?
What would we do with new types of events that embedding applications
might want to receive, such as test execution, file upload and download,
compile problems, web app deployment, etc? Do we add them to
ExecutionListener? What about such events that are already available,
such as project evaluation? Shouldn't these be on ExecutionListener as well?
I don't think having a single mega interface scales very well as the
interaction between Gradle and the embedding application gets richer
(particularly once we need to consider backwards compatibility).
Another, more flexible approach, is to simply make it easier to add
different types of listeners, at any time during the lifecycle, combined
with fine-grained listener interfaces (ie with a small number of
methods). Then you can choose which combination of events you are
interested in by implementing the appropriate interfaces. For example,
something like this:
Gradle gradle = ....
MyBuildListener listener = new MyBuildListener()
gradle.addTaskExecutionListener(listener)
gradle.addStdoutListener(listener)
gradle.addStderrListener(listener)
gradle.run()
Perhaps we could have a generic Gradle.addListener() which registers the
listener based on which listener interfaces it implements:
MyBuildListener listener = new MyBuildListener()
gradle.addListener(listener)
gradle.run()
Currently, getting this information requires adding multiple listeners at
different times. For example, you have to wait for
BuildListener.taskGraphPopulated to add a TaskExecutionListener. And hooking
into Log4J can be error prone if you don't setup things just right.
We definitely want to make this easier. I think the way to do this is
add a small, focused listener interface which you can register with the
Gradle class, something like:
LoggingListener {
void messageLogged(...)
}
And:
Gradle.addStdoutListener(LoggingListener l)
Gradle.addStderrListener(LoggingListener l)
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
