sebb>I did not ask for an exhaustive list, but some clue as to what you sebb>have run so others can repeat the tests on diferent hosts.
Well, I have already suggested to check if the project builds and/or if it loads into IDE, code navigation, autocomplete, etc, and other typical developers' tasks. It is by far the most significant improvement which Gradle brings. I could answer questions, however it should "just work". I do not intend to write an exhaustive documentation on how Gradle should be used. Gradle should work transparently behind the scenes, so regular Google/StackOverflow should answer all the typical questions immediately. sebb>See below for further technical reasons I'm sure the questions you list do not qualify as technical justification for the veto, however I'm not going to explain that further at the moment. My point is: A) There's nothing to veto yet B) I would prefer spend time on implementing features rather than arguing with you C) As the build script is ready, you might happen to allow it to be committed. If that happens, we all save the time in the first place D) Only in case you (or someone else) happen to claim a veto, then we would have an interesting conversation. Of course I would appreciate comments (e.g. Graham Russell noted I add duplicate lines in .gitignore), however I do not see how I could apply opinions like "I think". sebb> So what is ready for testing? 1) Building the project 2) Loading code to IDE 3) Running tests (certain tests fail still) 4) Adding more tests, adding features. For instance, we need to refactor "batchtests". One can take /gradle branch and develop the test there to see how development feels like. 5) Adding Gradle configuration. For instance, if someone is brave enough (s)he can try adding checkstyle or checksums or repeatable builds or maven poms or whatever. 6) Probably something else sebb> If a test fails Of course if a test is written in a cryptic way, then nothing could help. On the other hand, Gradle produces way better developer experience than the current codebase when it comes to testing/debugging/failure analysis. I'm sure you wouldn't ask those "is it because" if you had checked Travis output at least once: https://travis-ci.org/apache/jmeter/builds/499149535#L987 Running and debugging tests from IDE is much simpler with Gradle. For instance, current tests are full of assumptions like "certain commands must be executed before even trying to run the test". On the other hand, Gradle runs all the required commands automatically even if you checkout a brand-new project and ask it to execute a single specific test. So even if one faces a test failure, it would be much simpler to analyze / reproduce. sebb>we moved from /jakarta/jmeter to /jmeter when we sebb>went TLP and that did not cause any major issues as I recall Then you really don't have points to claim "file movement is bad" Vladimir
