Really impressive Dawid! I like how you were able to organize the build files, especially the hacks and keeping the build.gradle files relatively straightforward.
The dependency approach is totally good with me. It addresses the essential problem with pure Maven which is unknowingly sucking in transitive dependencies. Code reviews will continue to make new/updated dependencies visible as they are today by forcing the commit to include checksums 'n such. gradlew -p lucene test That took my machine 27 minutes! I can see it used like 7 threads when I'd rather it use 3-4. That's probably why. gradlew :helpAnt This failed: -- java.io.FileNotFoundException: /Users/dsmiley/DevSearch/lucene-solr/help/ant-gradle.txt (No such file or directory) seems like a simple error related to an incomplete rename or other refactor What gradlew command is the equivalent of "ant server" for Solr? I wish to use "bin/solr". I'm +1 with you committing to master as soon as you are comfortable. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Mon, Dec 2, 2019 at 11:36 AM Dawid Weiss <[email protected]> wrote: > > - run a single unit test (NOTE: one of the TODO’s is running the test > multiple times. Gradle defaults to marking a test as “good” once it passes > and doesn’t re-run it until there are code changes. This can be fixed) > > See gradlew :helpTests, Erick -- I corrected some of it today. In short: > > You can already run a single test multiple times with tests.iters > (passed via -P or -D). This works from IDEs as well (because it's the > runner's code, not gradle). Full 'beasting' mode is more difficult > because current working directories will overlap. I have some ideas > how this can be solved. > > I don't think we should force tests to re-run if nothing has changed. > If everything is up-to-date and no properties have changed, the tests > should skip. It really helps with incremental runs. Please note that > "nothing has changed" is tricky with gradle because it takes all the > properties, arguments, etc. passed to the test runner as input -- we > pick a random test seed on each run so tests should re-run > automatically because the seed will be different. However, if you run > the same seed multiple times over (gradlew test -Ptests.seed=deadbeef) > then it will indeed skip them. Finally, if you wish to force a re-run > of any task gradle gives you many options to do so (the simplest is to > add a forced "cleanXXX" of a task named XXX - try it: gradlew > cleanTest test -Ptests.seed=deadbeef). > > I will add this explanation to the tests help file. > > I've warned gradle can be frustratingly complex! (but once you learn > it it's fun ;). > > D. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
