On 23/02/2011, at 3:57 AM, Peter Niederwieser wrote: > > > 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.)
Treating the test includes as a project-level property is a good idea, I think. As for tasks, I think we want some better way to set project level properties from the command-line. Again, a custom command-line option feels like a nice thing to use, but something like this might be good too: gradle build test.includes=*MyTestPattern* (ie get rid of the -P for defining properties from the command-line, and fix things so that it works for convention properties, too). -- Adam Murdoch Gradle Developer http://www.gradle.org CTO, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
