Hans and Adam (and anyone else who might care), I'm about to start hacking at Gradle again. I've got two tasks on my list. I wanted to let both of you know that I'm working on these and see if you had any ideas or concerns before I get to far into it. I hope to work on these next week while I'm on Thanksgiving vacation (I have no idea how much I'll actually get done...).
First is TestListener. This (if you can recall that far back) was the reason I did the listener manager changes. We need to have an init script that can register a listener that gets testing feedback from JUnit. This will allow us to improve our Gradle TeamCity runner so that it gets better (and real time) test results. I'm thinking along the lines of "if a listener of a certain type is registered with the listener manager, then give a remoting listener to JUnit that sends messages to an in-process peer that forwards the messages on to the registered listener." Do that make sense? Second is extension support. This is the idea that a script can ask for some external script to be executed against a given delegate object. Doing this through Gradle would allow for all the normal caching stuff to be reused. We need to be able to run such scripts from the settings.gradle (and from inside build scripts, but that is obvious). We would use this feature to define our own custom domain objects that are configured via external script files. I'm not sure what the interface to Gradle should be, a method on Gradle called "executeExtension" that takes a file and a delegate object? Or maybe a "getExtensionSupport" method that returns an ExtensionSupport class that provides an execute method? What stateful information could ExtensionSupport have that justifies a separate class? Or maybe the justification is that it provides more than one method, like what? I'm not sure what you guys might be thinking about this feature as we have not discussed it much before. -- John Murph Automated Logic Research Team
