+1 for Gradle. We already have it and it already works. In addition, it’s Groovy DSL is often more concise than Maven. Also it’s daemon is a nice feature that can reduce build time quite nicely during development.
I will concede, though, that Maven has more support and a bigger following. — Steven Schroeder On Tue, Apr 30, 2019 at 09:59 Oleg Tikhonov <[email protected]> wrote: > I also do not have a vote, however +1 for gradle. Why go back? > > On Tue, Apr 30, 2019 at 5:26 PM Pierre Smits <[email protected]> > wrote: > > > +1 for moving away from Gradle. > > > > Having experienced it first-hand for a number of years in the Apache > OFBiz > > project (there the powers that be decided to migrate from Apache Ant to > > Gradle), I was confronted with undesirable side effects in production > > environments that required quite some additional considerations and > effort > > to mitigate. > > > > Best regards, > > > > Pierre Smits > > > > *Apache Trafodion <https://trafodion.apache.org>, Vice President* > > *Apache Directory <https://directory.apache.org>, PMC Member* > > Apache Incubator <https://incubator.apache.org>, committer > > *Apache OFBiz <https://ofbiz.apache.org>, contributor (without > privileges) > > since 2008* > > Apache Steve <https://steve.apache.org>, committer > > > > > > On Fri, Apr 26, 2019 at 5:17 PM Kenneth Knowles <[email protected]> wrote: > > > > > -0 > > > > > > I haven't started coding on Tuweni, so I don't deserve a vote. But Beam > > > moved from Maven to Gradle and it was a huge win. I think many of the > > > reasons apply here: > > > > > > - Maven doesn't do dependency-driven builds at the task level > > (--also-make > > > is not this; it is at the module level) > > > - Maven doesn't skip tasks that don't need rerunning > > > - You can't write custom tasks easily > > > > > > There are workarounds, generally a `mvn install` up front followed by > > > repeated `mvn --pl path/to/subproject task@id`. It isn't that great. > > Maven > > > is still just fine for individual modules, but for a multi-module > > project I > > > wouldn't choose it. Since you have a working multi-module gradle > build, I > > > wouldn't change. > > > > > > Kenn > > > > > > On Fri, Apr 26, 2019 at 7:34 AM Michael Wall <[email protected]> > wrote: > > > > > > > I am +0. I know maven much better, but gradle has some nice features > > > like > > > > the daemon and the application plugin. Is there something specific > you > > > are > > > > stuck on? Would it be worth evaluating making gradle better before > > > > switching? Happy to help either way. > > > > > > > > Mike > > > > > > > > On Fri, Apr 26, 2019 at 10:21 AM larry mccay <[email protected]> > > wrote: > > > > > > > > > They both have a sufficient level of black magic to make debugging > > hard > > > > but > > > > > I am more familiar with the pain associated with maven so here is > my > > > +1. > > > > > :) > > > > > > > > > > On Fri, Apr 26, 2019 at 6:11 AM Vinayakumar B < > > [email protected] > > > > > > > > > wrote: > > > > > > > > > > > Haven't used gradle, cant say anything particular about that.. > But > > > > maven > > > > > > will be easy to work with. > > > > > > > > > > > > So +1 for moving to maven builds. > > > > > > > > > > > > -Vinay > > > > > > > > > > > > On Fri, 26 Apr 2019, 1:28 pm Antoine Toulme, < > [email protected]> > > > > > wrote: > > > > > > > > > > > > > Hey folks, > > > > > > > > > > > > > > I am wondering if it might be worth moving to Maven. I’m saying > > > this > > > > > > after > > > > > > > spending the best part of 2 hours fixing the gradle build yet > > > again. > > > > > > > > > > > > > > Maven has a few advantages I wouldn’t mind: > > > > > > > -Better metadata > > > > > > > -Better support in Java space > > > > > > > -Gives us the ability to do OSGi artifacts too pretty easily > > > > > > > > > > > > > > There is nothing special in our build at this time. > > > > > > > > > > > > > > Anyone particularly interested to keep the Gradle build for any > > > > reason? > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Antoine > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
