++1 ! > 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
Vladimir please let's do it! -- Artem Fedorov On Thu, Feb 21, 2019 at 5:06 PM Andrey Pokhilko <a...@ya.ru> wrote: > ++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 > >> >
