On Thu, 21 Feb 2019 at 09:48, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> wrote: > > sebb> Whoever wants to switch should show that it can replace the current > sebb> Ant build system without causing disruption. > sebb> It needs to support all of the existing Ant targets. > > Ok, I read that as you agree to replace Ant with Gradle.
No, I did not agree to that. I would only agree if you can show that switching to Gradle won't affect current functionality. > So far the only technical justification (see > https://www.apache.org/foundation/voting.html#Veto ) I see is "Gradle might > fail to implement some of current build logic". > Of course the only way to prove that "Gradle fails to implement the > required tasks" is to actually implement the tasks. I agree there might be > issues, however I'm sure this fear alone does not qualify as "technical > justification". Huh? Of course that is a technical justification. > So far > ++1 (Binding): Vladimir Sitnikov > ++1 (Binding): Philippe Mouawad > > Vetos: none -1 from me unless Gradle can be shown to be equivalent. > sebb> (The Ant scripts don't change that often, so that should not be too > difficult). > > Maintenance of multiple build systems at once is always a time consuming > task. Of course, but my point was that we rarely need to change Ant, so there should not be much/any parallel maintenance. Assuming that the Gradle build proves to work, at that point the Ant build can be dropped (and the build docs updated) > We don't seem to have funding for that, so I suggest we just implement > Gradle build as a branch, and merge that in a single go. What's funding got to do with anything? > sebb> Why use a build system that all but forces a change on you? > > Sebb, I don't suggest Gradle just because it forces to move files around. My comment above was related to Maven, not Gradle. If Gradle forces files to be moved, then it is a reason not to use it. > I suggest Gradle since it simplifies day-to-day coding activities like: > 1) loading JMeter project to IDE > 2) building JMeter > 3) testing JMeter > 4) dependency management > 5) other Those are mere assertions, and have to be justified/shown to be true in practise. > On top of that, there are good reasons for certain folder layout. Of course, but AFAICT that is not really relevant to whether to use Gradle or not. > For instance, Gradle encourages to keep dependency jar files in a > completely separate folder (outside of the project). That could affect JMeter at run-time. > This prevents accidentally putting multi-megabyte blobs under source > control like in > https://github.com/apache/jmeter/commit/c9a4d557f9a8e213ccc93215264a254dfb2bc50a > Then it makes sense to keep test classes close to the relevant code. > Otherwise the codebase looks like a single module which really takes time > to comprehend. > Currently all the test code is located in a single folder/structure, and it > is not clear which tests are related to which jars. I agree the test code could perhaps be moved. > So moving files around it not just to make Gradle happy, but it is more to > make developers who read and maintain the code happy. Again, that is just an assertion. > sebb> Note that the current Ant build relies on some Beanshell scripting and > sebb> Maven integration. > > Gradle approach there would be to use Java (or Kotlin) code and place it in > buildSrc folder. > Gradle builds buildSrc code at build script initialization, and buildSrc > code can represent whatever build logic is required > Doc: > https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:build_sources > > Apparently, Java/Kotlin code is way better than Beanshell. Should I > elaborate? My point was that the Ant build uses Beanshell to perform certain functions, and these are relatively complicated (otherwise it would not have been necessary to use a scripting language such as BSH) These functions need to be supported by Gradle. It does not have to use BeanShell, but must produce the same result. Since this part of the conversion is likely to give the most trouble, it should be tackled early on to avoid wasted effort. > Vladimir
