Adam Murdoch-3 wrote: > > Instead, I think a command-line option might be better: > > gradle test --include SomePattern > > and > > gradle core:test --include SomePattern plugins:test --include > SomeOtherPattern > > Or, more generally: > > gradle <task-independent-options> [<task> <task-specific-options>]... >
First of all, I agree that tasks shouldn't be configured with system properties. Of course, we could have a generic mechanism that maps system properties to task properties, like we already have for project properties. But tasks shouldn't "own" any system properties, because this leads to all the problems you've described. Having a way to set task properties from the command-line could be helpful, and I've missed it a few times already. In the case of test filtering, I'd probably prefer a task-independent option, so that filtering would also work with, say, "gradle build", and also across test tasks. So maybe what I'm really looking for is a project convention property, along with a way to set such properties from the command-line. (-P only works for statically declared properties at the moment.) -- Peter Niederwieser Developer, Gradle http://www.gradle.org Trainer & Consultant, Gradle Inc. http://www.gradle.biz Creator, Spock Framework http://spockframework.org -- View this message in context: http://gradle.1045684.n5.nabble.com/Simplifying-the-execution-of-single-test-classes-tp3394412p3395808.html Sent from the gradle-dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
