Gradle allows to hack something much quicker. In Maven you would need to write a plugin.
Otoh I've seen a Gradle project which went from great to barely maintainable in almost under a year. Just let a few juniors touch the build and you are doomed pretty quickly. The approach of gradle is not new. Check buildr [1] which does almost the same but in ruby instead of groovy. And I think it even predates gradle. That was great too in the beginning, but after 3 years the projects were insanely broken and we moved them back to maven again. "With great power comes great responsibility" (Starwars? Kung-fu panda? not sure anymore :) LieGrue, strub [1] http://buildr.apache.org/ ----- Original Message ----- > From: Paul King <pa...@asert.com.au> > To: Maven Users List <users@maven.apache.org> > Cc: > Sent: Tuesday, September 11, 2012 11:30 AM > Subject: Re: Arguments for Maven vs. Gradle > > You will have to make your own assessment but most new projects I see in my > customer base are moving over to gradle. It offers the same convention over > configuration advantages of Maven but with some flexibility if you need it, > plus a whole swag of benefits that are gradle specific. The dependency > management story is practically identical to the maven world. > > Cheers, Paul. > > On Tue, Sep 11, 2012 at 4:28 PM, Baptiste MATHUS <m...@batmat.net> wrote: > >> (Disclaimer: I only know Gradle from outside. I never used it more than 2 >> minutes, but I read some things about and saw a prez at our JUG.) >> Gradle has a very different approach: where Maven values sometimes not much >> flexibility at first sight (to improve build genericity, as already said), >> Gradle lets you change anything you want. The good thing is that Gradle >> comes with some standard process if you want to go Maven-style (meaning the >> standard fits your needs). But then you can plug whatever you want, the way >> you want, anytime you want (using Groovy scripting code). >> >> By the way, that last statement is the kind of things that makes Gradle >> appear to Maven-fans as no-good. In fact, for the record, Maven 1 was using >> a scripting language (Jelly), and being able to clutter your build file >> with scripts is just a bad idea. >> >> About Maven coordinates, yes Gradle can use them. I seem to remember >> they're actually using Ivy as their dependency management tool. >> By the way, you can disable transitive dependencies, etc. >> >> > http://gradle.org/docs/current/userguide/dependency_management.html#defineConfiguration >> >> Cheers >> >> 2012/9/10 KARR, DAVID <dk0...@att.com> >> >> > > -----Original Message----- >> > > From: Ron Wheeler [mailto:rwhee...@artifact-software.com] >> > > Sent: Sunday, September 09, 2012 4:43 PM >> > > To: users@maven.apache.org >> > > Subject: Re: Arguments for Maven vs. Gradle >> > > >> > > Moving from Ant to Maven is a change of attitude. >> > > You are right that Maven does make builds much more uniform. >> > > Once a project is set up, the next guy to work on it only has to > write >> > > code and add dependencies, the rest of the environment is laid > out. >> > > >> > > Never heard of Gradle so I can not compare them. >> > > >> > > Maven has a huge following and almost any library that you want > to use >> > > has a Maven distribution available at Maven Central or in a > public repo >> > > that you can connect to . >> > > Saves a lot of grief. >> > > >> > > If you go with Maven, get your own repo set up before you unleash > the >> > > developers. >> > >> > Thanks. >> > >> > Not that I disagree with your overall conclusion, but I would point > out >> > that Gradle makes it easy to specify dependencies through Maven >> > coordinates. I would assume that means it also handles transitive >> > dependencies, but I'm not sure. It's a good idea to > "know your enemy", >> not >> > that I consider Gradle an "enemy" in any way. >> > >> > > On 09/09/2012 5:20 PM, KARR, DAVID wrote: >> > > > At the risk of starting a flame war, what are some arguments > for >> > > Maven vs. Gradle? >> > > > >> > > > This is in the context of a change and risk-averse > organization that >> > > currently has a large Ant build, although with some associated > Maven >> > > builds. >> > > > >> > > > I see the advantages of Gradle as a much better Ant, but I > would be >> > > concerned about losing the advantages of Maven, like better > integrated >> > > tool support. >> > > > >> > > > One of the disadvantages of Gradle is the same as Ant, which > is that >> > > it's very easy to have two people do similar things in a > completely >> > > different way. Gradle makes it easier to reuse things, but it > doesn't >> > > seem like it nudges you that hard in that direction. >> > > > >> > > > I can see the possibility of calling Groovy from Maven, but > having >> > > that be Gradle code would require the Gradle runtime, and I > don't see a >> > > "Gradle Maven plugin" yet (although I believe I've > seen a "Maven Gradle >> > > plugin). Even if you could do this, I'm not sure it makes > sense or >> > > provides significant value. >> > > > >> > > > > --------------------------------------------------------------------- >> > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> > > > For additional commands, e-mail: users-h...@maven.apache.org >> > > > >> > > > >> > > >> > > >> > > -- >> > > Ron Wheeler >> > > President >> > > Artifact Software Inc >> > > email: rwhee...@artifact-software.com >> > > skype: ronaldmwheeler >> > > phone: 866-970-2435, ext 102 >> > > >> > > >> > > > --------------------------------------------------------------------- >> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> > > For additional commands, e-mail: users-h...@maven.apache.org >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> > For additional commands, e-mail: users-h...@maven.apache.org >> > >> > -- >> > Baptiste <Batmat> MATHUS - http://batmat.net >> > Sauvez un arbre, >> > Mangez un castor ! >> > nbsp;! >> > <users-h...@maven.apache.org> >> > <users-h...@maven.apache.org> >> > >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
