Some misc questions after playing around with gradle on this branch for a bit today in no particular order...
: tests_jvms=5 ... : test_jvms is controlled by us and defaults to the number of cores detected : / 2. If tests_jvms is a lucene/solr specific property, that needs to be in a users "multi-project" "~/.gradle" file ... shouldn't we name it namespace it with something like "lucene_solr_test_jvms" to make that clear reduce future confusion/collsion? (as i anticipate this wo't be the last prop we may need) How do we get "reproduce with" type output (by default) when a test fails? For that matter, how do we get *all* of the logging from failed tests to be written to stdout/stderr when a test fail? ... this is pretty important for making jenkin's console log a good "one stop shop" for understanding everything that went wrong in a build. ("--debug" and "--info" seem to do this, but they write a *TON* more gradle specific shit then "ant test" type logging use to produce by default, and don't care if the test passes or not ... which would make them way too excessively verbose for a jenkins build) What's the plan as far as things like "ant beast", "-Dtests.dups", "-Dtests.iters" & "-Dtests.jvms" ? ... those types of options are all pretty critical for diagnosing and troubleshooting failures. ("-Dtests.jvms=1" is important for figuring out if/how the execution of one test might polute static variables in the JVM that cause a failure in a subsequent class in the sane JVM) is there a simple option to prevent gradle from using curses even though it detects it's being run in a tty? -Hoss http://www.lucidworks.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org