2009/11/20 Adam Murdoch <[email protected]> > > > John Murph wrote: > >> Hans and Adam (and anyone else who might care), >> >> I'm about to start hacking at Gradle again. >> > > Excellent. > > > 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? >> > > This would be nice to have. > > I suspect most of the work has been done already in the NativeTest task, so > that the events are available just below the surface of the NativeTest task. > We'd need to add some methods for adding a TestListener to NativeTest, with > an impl of that used a ListenerManager to create its broadcaster. Then, the > TestListener events would be available in the init script. > > I don't think we should bother with trying to fit this into the AntTest > task as well, and should instead focus on getting the NativeTest stuff > ready. > > I'm currently working in this area (reporting / listeners) of the native test stuff, I have added a basic to console report based on the events the test execution provides. The next step would be to have the reports as a realy listener and add the listener infrastructure. One thing we need to keep in mind is that the execution is really parallel and the CI listeners are probably expecting serial invocation, so we have to foresee this. If you'd like we can have a skype-session about this.
> > >> 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. >> >> > Why do you need to do the configuration using external scripts? What do > they configure? I want to get a feel for the use case before we discuss a > solution. > > -- > Adam Murdoch > Gradle Developer > http://www.gradle.org > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
