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 >
