On Thu, 21 Feb 2019 at 13:14, Philippe Mouawad <philippe.moua...@gmail.com> wrote: > > On Thursday, February 21, 2019, sebb <seb...@gmail.com> wrote: > > > 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. > > > it’s based on 4 experiences already. > Like it or not, Ant is no more a standard although it’s great. > Dependency management that maven/gradle offer are the missing piece. > > > And nowadays, when you pick on OSS project, you import in your ide either > through maven or gradle, they are the standards. > Yes Ant does the job for us, but it doesn’t mean we can’t improve. > Bringing new developers on the project is also a target for us. > > We already saw an increase in contributions when we started using our > github mirror, adopting nowadays tools is criticial. > > And IMO, it can be an opportunity to improve also release process which > slows down the releases. > > > > > > > I have my doubts. > > > > Are the problems new developers experience actually anything to do > > with the build system? > > > Yes IME
Such as? > > > Or are they issues in the tests? > > > Yes, there is also room for improvement on tests side. > Graham and Felix improved this a lot. > > - 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? > > > I think documentation is probably the best among all tools I use. > But as you know, nobody reads it. > > When people select a tool, which one gets better opinion : > - the one that builds immediately after download and import in IdE > - or the one that works after reading a long doc and tweaking, asking on > mailing list... Surely that is more a question of which IDE is used? > > 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. > > > I guess that’s what Vladimir will do with a pr or a branch > > > > > We should not just assume that it's going to be better (or even possible). > > > why be negative before trying? I'm all for try before buy. What you seem to be saying is that we should swap to Gradle without any further investigation. Gradle may be the 'new' tool, and may well be better, but new is not always better. Sorry, but I need some proof. > > > > > So yes, at this point I suppose you could say that I would veto > > switching to Gradle. > > > I don’ t share this approach. > IMO it discourages enthusiasts. > IMO, if a PR shows gradle works and does the job, there is no reason for > vetoing. That is not my position at all. I am not vetoing the use of Gradle. But I would veto a change to Gradle without first proving that it works. I see this as being similar to insisting on a unit test before accepting some new functionality. I hope you all agree that unit tests are essential, especially for something that affects the entire product. > > > > > 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) > > > let’s us see what Vladimir will do, I am confident he will succeed. > > > > > > 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. > > > We all agree I think > > > > > > > > > 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/c9a4d557f9a8e213ccc93215264a25 > > 4dfb2bc50a > > > > > 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. > > > > > -- > Cordialement. > Philippe Mouawad.
