-0.5 from me, to have suffered from projects having done it I think it wouldn't be sane for commons Big advantage of gradle is to be flexible but it also means you do a one man build, lose most of the IDE integration (even IDEA integration is not good, you often must use gradle runner to run test cause idea runner does not understand what you did in your script which completely defeats any speed improvement in dev cause it rereads and executes the whole script whereas with maven integration is just about incremental compilation and run the test (was a +3s with gradle on Apache Beam for example when they moved to gradle - and, side note, Spring can be a success cause they are great but Apache Beam move is likely a failure cause the move was motivated by speed and the diff was 10mn on 2h only + they lost a big part of the community and even core contributors with that move) and likely the worse for me is to have false positive green builds due to the over incremental support - run -> test fails, rerun -> no change so skip it so build is green - of gradle (indeed you can configure it to not be like that but it is highly likely you get that). Last point is that it is way way less known than maven, even today, and decreases general contributions which would be negative for generic projects as commons is IMHO. So overall, for super specific projects with an "expert" community I'd say whatever works for the community is good but not as a generic option.
Side note: also means commons pom must be recoded and maintain for gradle, no? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 17 juil. 2020 à 01:12, Singh, Baljit (GE Aviation, US) < balsi...@ge.com> a écrit : > +1 from me. I prefer Gradle for two main reasons: > - Control over how a library's dependencies are exposed ("api" vs > "implementation", see > https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_configurations_graph > ) > - build.gradle is a lot simpler and a lot less verbose than pom.xml > > Drawback: Maven probably has a lot more plugins. > > > On 7/16/20, 7:00 PM, "Alex Remily" <alex.rem...@gmail.com> wrote: > > For those of us not as familiar with Gradle, what are some of the > benefits? Drawbacks? > > On Thu, Jul 16, 2020 at 5:30 PM Rob Tompkins <chtom...@gmail.com> > wrote: > > > > I think we might be coming towards time to make this move or at > least accommodate for gradle builds in commons. Let’s look to the success > the Spring Framework has had here with gradle. That said, I’m merely trying > to gauge opinions here and am entirely content to stay with maven, if > that’s what the community wishes. > > > > I’m a +1 on at least letting gradle be a part of our systems (don’t > have to get rid of maven either). > > > > Cheers, > > -Rob > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org >
