On 26/08/2011, at 6:19 PM, Luke Daley wrote: > > On 26/08/2011, at 4:56 AM, Adam Murdoch wrote: > >> On 25/08/2011, at 11:58 PM, Luke Daley wrote: >> >>> Hi, >>> >>> I am working on some bits around our integration testing fixtures and >>> thinking about what a publicly usable version of this might be like. >>> >>> Do you think we would want to allow people to execute Gradle in different >>> manners like we do? If I'm developing a plugin and want to integration >>> test, am I really going to want to test with the daemon, and embedded etc? >>> >>> Initially, I was inclined to think that we should *only* support testing >>> using a forking mode (daemon or not) but I guess users will want to have >>> the choice of making the same tradeoff that we do where we run embedded for >>> speed during development and trade off accuracy. >> >> I can think of a couple of problems with forking mode, from a developer >> point of view: >> >> * You can't (easily) debug the code under test in the IDE. >> >> * You can't (easily) inspect the state of the model in the test, similar to >> what our plugin unit tests do. >> >> A simple solution to the first problem is to have some way to run the test >> build in-process. We can make our current in-process executor much more >> accurate by having it use the tooling API in in-process mode, which better >> isolates things from each other. Plus you don't necessarily need all of the >> Gradle runtime on your classpath to use it. If we were to do this, I'd make >> in-process the default mode for test build execution (in fact, I think I'd >> always make it the default, regardless of accuracy, because it's so much >> more usable). > > Makes sense. > > Does the tooling-api currently support this in process mode? Seems like this > would be reliant on the daemon supporting an in process mode (which is next > on my to-do list).
It does. Have a look in o.g.tooling.internal.provider.DefaultConnection. We can probably replace what's there with an in-process daemon. > > We're also going to need to support using the tooling-api with a custom > classpath so the user's classes are exposed to the gradle version the tooling > api is driving. Or, we force it all to be packaged up into a distribution of > course but that doesn't seem good. A very good point. Perhaps some way for the test to say 'make my classpath available to all build scripts' would be useful. Perhaps this even happens automatically when you use the test fixtures. Certainly this is what our test fixtures do now, for our plugins, and this is very useful, as I can just run the test in the IDE and have everything just work. This kind of capability might be useful for other clients of the tooling API, too. > >> Not sure what to do about the second option. For that to work, you'd need at >> least all of the Gradle API on the test classpath. Might be interesting to >> offer an in-classloader execution mode for the tooling API. This way, a >> client of the tooling API, not just tests, can tightly couple itself to a >> particular Gradle version, but in making that trade-off can use all of the >> model. > > I can see that being very useful. It seems logical that people would want to > poke around the model after running some tasks. I'd much rather we ended up with full control over the classloading of the core and plugin classes, so it would be nice to avoid this mode. Perhaps if we make it easy for tests to inject code into the build, we don't need this mode. We could possibly just inject the tests themselves and run them in the build environment, regardless of where that happens to be. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
