On Thu, 21 Feb 2019 at 10:29, Philippe Mouawad <philippe.moua...@gmail.com> wrote: > > 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.
Yes - that is currently just a *guess* - it remains to be seen. I have my doubts. Are the problems new developers experience actually anything to do with the build system? Or are they issues in the tests? - e.g. some tests make assumptions about the environment that might not be true, and the error message does not relate to the underlying cause. Or issues in documentation? In other words, I think the setup issue is tangential to the question of whether Gradle is better than Ant. > sebb, are you vetoing this change ? As I already wrote, it needs to be shown that Gradle can properly replace Ant. We should not just assume that it's going to be better (or even possible). So yes, at this point I suppose you could say that I would veto switching to Gradle. But if it can be proved to work, then I would drop the veto - unless Gradle turned out to be much more complicated than Ant (that is probably not going to be the case, but at present there is no evidence that it will be simpler for JMeter) > If Vladimir works in a branch or with a PR, why would be block it ? I never said that. It's obviously fine to work on a PoC (proof of concept) so long as it does not impact current development unduly. > > Thanks > > On Thu, Feb 21, 2019 at 11:23 AM sebb <seb...@gmail.com> wrote: > > > On Thu, 21 Feb 2019 at 09:48, Vladimir Sitnikov > > <sitnikov.vladi...@gmail.com> 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.
