++1 from me. Any change to modern is better, contributors will appreciate the good modern tooling. As for plugins, source layout does not affect them, as long as lib+lib/ext are kept for libs and plugins in distribution structure.
-- Andrey Pokhilko 21.02.2019 13:00, Antonio Gomes Rodrigues пишет: > Hi, > > No experience in Gradle, but ++1 (Binding) to replace ant > > Antonio > > Le jeu. 21 févr. 2019 à 10:48, Vladimir Sitnikov < > sitnikov.vladi...@gmail.com> a écrit : > >> 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 >>
