On Thu, Feb 21, 2019 at 4:34 PM sebb <seb...@gmail.com> wrote: > 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? > Exposed above
> > > > > > 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? > If you use Eclipse or Intellij (and I think Netbeans also since PR was proposed by Netbeans committer), they accept maven/gradle format. > > > > > 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 Certainly not. I am of course waiting for PR. I am confident it will do it, it is used by Spring Source and those guys are rather very smart. I use more Maven, but I think here, Gradle looks a better candidate > . > > Gradle may be the 'new' tool, and may well be better, but new is not > always better. > Gradle is not that new, initial release was 12 years ago. It's a standard. > > 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. > ok then we're ok, and I'm sure we will move forward. > 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. > Yes. > > > > > > > > > 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. > -- Cordialement. Philippe Mouawad.
