: which should be a matter of project-local settings. Ideally, I'd like
: to see something like:
:
: checkout/gradle-defaults.properties [versioned]
: checkout/gradle-local.properties [developer-tweaks, not versioned]
:
: but short of declaring a custom "user home" for gradle (-g switch) I
: don't see how this can be achieved. Perhaps the initial checkout could
I gather from your comments (and from the link you mentioned in another
question) that gradle does not have a direct equivilent of ant's...
<property file="${user.home}/lucene.build.properties"/>
...but some naive google searching suggests it's possible to do something
similar using "apply from" to load in a *.gradle file using an arbitrary
path, which could contain property declarations which would then evidently
by overlayed on the existing groovy file?
(maybe?)
Ex: this in our build.gradle file...
apply from: '$USER_HOME/lucene.properties.gradle'
...and this in my ~/lucene.properties.gradle file...
ext {
test_jvms = 42
}
...would that work?
: > ("-Dtests.jvms=1" is important for figuring out if/how the execution
: of one test might polute static variables in the JVM
:
: I don't think it'll work even if you have one JVM unless Gradle test
: runner's order is deterministic... which I'm not sure it is, even with
: a single JVM that runs the tests.
FWIW: I'm not sure if the deterministic ordering is that important --
although you reminded me that being able to *review* the list of tests
that ran in the same JVM when a failure happens is helpful...
(i don't know that i've ever tried to rerun that exact list of every test
that ran in the same JVM in the same order as what was reported -- or even
how i would if i wanted to other then with a really fucking complicated
-Dtests.class=... param)
I'd guess that 90% of the time when i currently use "-Dtests.jvms=1" it's
when running a single test class with -Dtests.dups=N to confirm & fix
shitty use of statics in BeforeClass/AfterClass methods (typically
problematic if/when the jenkins [repro] target does something like
-Dtests.dups=5 -DtestcaseSomeTestThatFailed but defaults to using
tests.jvms=3, so we see 2/5 suite level failures that look nothing like
whatever the original failure was that jenkins was attempting to
reproduce)
the 10% of the time -- where that's not the issue, and a failure in one
test really was caused byt some previous test in the same JVM mucking up
some static variable state -- eyeballing the list of tests that also ran
in that JVM usually helps narrow down the list of suspects, and then i
just try beasting those 2 (or 3) tests together with "-Dtests.jvms=1", not
worrying about the order and just trusting that if i'm right eventually
they'll be run in the problematic order.
-Hoss
http://www.lucidworks.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
