I like the direction the Gradle work is going. Thank you for all your time and effort Vladimir! It's great when I can simply point to one file, with no other steps (documented or not) and have everything import, download, build and run tests via the IDE (IntelliJ for me but I would imagine it's the same for Eclipse?). I also like the use of Kotlin instead of Groovy (I've only recently discovered Kotlin but love it already).
I support the move of files around, version control should cope and it will soon be a minor historical blip. However, I agree with Sebb in that it is difficult to review and mistakes will likely be made due to the other changes happening on trunk (sorry some were me). May I suggest that we try to move the source files in trunk (and of course get ant to work but I don't know how hard that might be)? This should be far easier to develop this Gradle PR and merge it when the time comes. But, going even further, to prevent a lot of work (and effort and good will), separate to trunk, potentially being discarded, can we get both Ant and Gradle working together in trunk? We can continue to develop Gradle in small, tested, iterative steps, while still being able to fall back to Ant if required (or preferred) until we are all happy Gradle does all the things we need it to do? This seems too large a task not to do in a CI fashion? I'm worried that as the bulid.xml file is 3000 lines long and we are trying to replace it without rationalising what is and isn't required this seems risky. May I suggest that we have a clear set of goals that, once Gradle can do, we are happy to switch? e.g. - Compile - Mange dependencies - Run Unit Test (Spock and JUnit) - Run Unit Tests from IDE (I was working on an improvement for this as some of the JMeterSpec and JmeterTestCase look for properties files in relative locations, which with the new source structure is different) - Run batch tests (ideally in parallel, unlike the current ant scripts) - Run checkstyle - Make sure tests are run with coverage enabled/reported - Package and sign a release (maybe this could be a separate script which does the co-ordination and singing etc.) - Documentation (Sebb for details on what each one you mentioned below does, can we look in the ant build script?) - Generate Javadocs - Printable docs - website docs - Staging - Release promotion - Generation of Maven artifacts Thanks Graham On Wed, 27 Feb 2019 at 18:52, sebb <seb...@gmail.com> wrote: > > On Wed, 27 Feb 2019 at 18:15, Vladimir Sitnikov > <sitnikov.vladi...@gmail.com> wrote: > > > > 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. > > Again, I am not asking for extensive explanations. > Just list a few Gradle commands that should be tried. > > For example, in the Ant case, I would suggest people try: > Ant clean > Ant package > Ant test > Ant junit -Dtest.case=xxx > Ant printable-docs > > etc > > > 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 > > Not sure what build script you are referring to. > > > 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 > > Does it create the jars, or just the classes? > > > 2) Loading code to IDE > > Which IDEs have you tried? > > > 3) Running tests (certain tests fail still) > > How many tests are run, and how many fail? > > Why do they fail? > > > 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. > > Are these 'more tests' new tests, or do you mean tests which have not > been transferred from the Ant build and need to be created? > > > 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 > > I can think of at least: > Javadocs > Printable docs > website docs > Staging > Release promotion > Generation of Maven artifacts > Documentation > > > 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. > > That's not my experience, but I am used to Ant output. > > > 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 > > That means nothing to me. > > > 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". > > That's true of some tests, but most will run independently. > > > 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. > > How does Gradle know what the required commands are? > Don't you have to tell it? i.e. Gradle itself does not automatically > fix the problem, though it may well be easier to specify the > pre-requisites. > > > So even if one faces a test failure, it would be much simpler to analyze / > > reproduce. > > In which case it should not take long to fix all the current failures. > > > 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" > > In that case, the relative locations of files within the project did not > change. > Only the top-level changed, and developers just had to update the > workspace SVN URL. > The workspace layout did not change. > > That is very different from the moves you are proposing. > > There may well be assumptions in the code about the relative location of > files. > Changes to these locations can cause tests to fail in various ways. > It won't always be obvious which failures are be due to changes in > file locations. > > That is one reason why I say that the file moves are best done separately. > > > Vladimir
