> Great work Dawid. Just trying out solr tests now. A full suite of solr and lucene takes ~50 minutes... And I think it's pretty much the same with ant now (?).
> I see that it is not very smart in parallel scheduling. But that is probably > something we can improve over time? Maybe. I don't think it's going to improve things significantly though. It'd take some deeper restructuring of the codebase to get them to run faster. > Is there some env.var or global setting to force e.g. -Ptests.seed=deadbeef > for faster runs? Fixing the seed should be only done if you want to run two consecutive times with exactly the same combination of components. Don't fix it locally forever, please. Those randomizations are really effective to discover odd stuff (even at the JVM bugs level...). > We probably don’t need to randomize everything everywhere every time? Perhaps some of the stuff we do statically at test suite level (LuceneTestCase etc.) is too eager... I didn't look into this. But overall I disagree with Mark here -- I still have faith in that randomization of components has value to it. > Also, I like your moving of build files from the source tree. Will soon get > used to gradlew -p solr/packaging assemble. > Wonder how this will work with Admin UI changes. Hopefully you can just run a > new assemble and reload browser on each change. If you wish to rerun assembly with a server running in the background it may be tricky because some files may be locked by live processes (applies to Windows in particular) and some files generated by the server (logs, etc.) may be removed by the sync (since it's a sync, not a copy). Working on "live" files served via http is indeed going to be tricky. You could always work on those files inside the assembled distribution and copy them over to the sources once done... not a solution but a workaround. D. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org