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.
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
