On Fri, Nov 20, 2009 at 3:53 PM, Adam Murdoch <[email protected]> wrote:
> >> >> 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. > > OK, I'll have a look at the NativeTest stuff and see what I can figure out. This is the change that is most pressing for us as we currently don't have a workaround, so hopefully I can figure something out. > > >> 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. > > We showed and explained this to Hans when he was here. It's a bit difficult to explain in an email, but let me try. We have the concept of multiple modules being put together to form products, and multiple products forming installs and multiple installs forming distributions. Each of these three levels (products, install, dists) have logic and therefore need configuration of that logic. For example, what modules does this product need? What is the name of the product? What native launchers does the product need, and what are it's settings (Xmx, etc.)? Similarly, installs and distributions have configurations as well. To support this, we have three domain objects in our buildSrc that hold this information. We also have various "xxx_product.gradle" and "xxx_install.gradle" and "xxx_dist.gradle" files in our project that are used depending on what is being built. These special .gradle files are executed on the associated domain object by our settings.gradle. This allows our developers to only say what's important to them, and not have to see our giant build.gradle scripts (or our buildSrc module). What our developers actually think is Gradle is all these special scripts, they never see "true" Gradle. The thing is that I want these special Gradle files to be very similar in treatment to normal Gradle files. All I'm really doing is extending the concepts that Gradle knows about into my own custom domain. (This ability is at the heart of what we love so much about Gradle.) Unfortunately, to do this right now I had to copy-paste some Gradle implementation code into our buildSrc (the stuff than runs a script, knows when/where to cache it, knows when to ignore the cache and rebuild it, knows how to "delegate" to an object, etc.) Every time you guys touch that stuff it breaks us, because we are using internal APIs of Gradle. The idea of this feature is to make an easy to use public API so that we don't get broken so much. It will also make it easier for others to do this same thing. As a matter of fact, we've talked to Hans about our idea that large projects should generally be structured this way. I don't want to go into details right now (I intended to write up something more complete eventually), but most large projects have lots of concepts centered around what they are doing and the way they work. Formalizing those concepts into "extensions" to Gradle can product a much easier to use build engine that is designed for them. It's why I've always agreed that Gradle should be a toolkit. One that works out-of-the-box for simple projects, and one that lets large projects implement their own custom build engine on top of it. Part of the power of Gradle is that it can be both. -- John Murph Automated Logic Research Team
