IMO, if Vladimir is willing to do migration to Gradle (of course providing alternative or equivalent to existing tasks), we should not stop him because it is a change that might be impacting. JMeter is not a frozen project and temporary chaos is acceptable and it's life.
JMeter lacks easy setup for developers and new comers. I see it every time I jump start a developer on it. I guess a migration to gradle will fix this. sebb, are you vetoing this change ? If Vladimir works in a branch or with a PR, why would be block it ? Thanks On Thu, Feb 21, 2019 at 11:23 AM sebb <[email protected]> wrote: > On Thu, 21 Feb 2019 at 09:48, Vladimir Sitnikov > <[email protected]> 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 > -- Cordialement. Philippe Mouawad.
