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
