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. 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". So far ++1 (Binding): Vladimir Sitnikov ++1 (Binding): Philippe Mouawad Vetos: none 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. 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. 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. 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 On top of that, there are good reasons for certain folder layout. For instance, Gradle encourages to keep dependency jar files in a completely separate folder (outside of the project). 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. 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. 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? Vladimir
