Hi, I really like how the stdout/err capture stuff looks. Some comments:
1. I wonder if we shouldn't always capture stdout and stderr, and have captureStandardOutput() simply change the levels. Then, all logging, whether done via a logging framework or stdout/stderr, would always end up routed through logback, which would mean, for example, that it would end up in the log file, or that a listener could decorate it in some way.
2. It would be good if the source of the logging were considered when routing info/stdout messages.
For example, a call to logger.info() or println() in my build.gradle is almost always interesting to me when I run Gradle, and should be printed on the console when I run with default options (ie should be treated as a lifecycle message). However, a similar call in a java library used by an ant task used by a plugin is not interesting to me at all, and should not be shown when I run with default options (ie should be treated as an info message). There's a spectrum of interestingness going on here, and I'm not sure how we decide whether an info/stdout message is interesting enough to treat as a lifecycle message.
The same thing probably applies to warning and error messages. Some warnings are just noise to me when I run Gradle, and some are interesting.
3. Task.captureStandardOutput() and Project.captureStandardOutput() have inconsistent semantics. For Task, a call to captureStandardOutput() declares 'whenever I execute, capture standard output'. For Project, a call to captureStandardOutput() says 'capture standard output now until forever'.
I prefer the Task semantics. I think Project.captureStandardOutput() should behave in a similar way. It should declare that when the project is evaluated, standard output should be captured. If captureStandardOutput() happens to be called as the project is being evaluated, then is should take effect immediately. And when evaluation completes, it should restore to what it was when evaluation started.
This means, for example, that the logging for a project can be configured from somewhere else (a parent project, say) without affecting the logging of the configurer. It also means that the logging for a project does not affect the logging of other projects which are implicitly evaluated during the evaluation of the project, eg by a call to dependsOn().
4. StandardOutputLoggingAdapter is not thread safe. Although Gradle isn't multithreaded (yet), there's plenty of potential for things to execute which are, and which assume it is safe to use System.out from multiple threads. We really should make it thread safe. A buffer per-thread would be kinda nice, but a big fat lock around each method would do the trick too.
Adam --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
