Hi everyone, > Just let a few juniors touch the build and you are doomed pretty quickly.
I agree, and would generalize this statement to any build system I've ever designed or worked with: shell scripts, Makefiles, Ant, Maven... it doesn't matter. A build is a very finicky thing, especially for medium-to-large projects, and increasingly so as it adds gravy to the build process. I'm not advocating that junior developers not be allowed to touch the build—otherwise how will they learn?—but I strongly recommend code review of any changes a junior developer makes to a build system. In particular, my experience with most junior developers is that they prefer graphical tools and IDEs over the command line. So even though Maven is much more standardized than, say, Ant, it is easy to screw up a Maven build by editing the POMs using e.g. the Eclipse/M2E tabbed POM editor. (One of many examples: if you use properties to define dependency versions, the graphical editor will not know to use them when adding new dependencies.) [Buildr] was great too in the beginning, but after 3 years the projects > were insanely broken and we moved them back to maven again. I definitely agree that making it harder to swim upstream against the convention also makes it harder to wreck a build. That said, breaking complex technical stuff will always be extremely doable for the clueless. CI and unit testing (and someone with a clue) to the rescue! Regards, Curtis On Tue, Sep 11, 2012 at 5:04 AM, Mark Struberg <[email protected]> wrote: > 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 <[email protected]> > > To: Maven Users List <[email protected]> > > 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 <[email protected]> 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 <[email protected]> > >> > >> > > -----Original Message----- > >> > > From: Ron Wheeler [mailto:[email protected]] > >> > > Sent: Sunday, September 09, 2012 4:43 PM > >> > > To: [email protected] > >> > > 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: [email protected] > >> > > > For additional commands, e-mail: [email protected] > >> > > > > >> > > > > >> > > > >> > > > >> > > -- > >> > > Ron Wheeler > >> > > President > >> > > Artifact Software Inc > >> > > email: [email protected] > >> > > skype: ronaldmwheeler > >> > > phone: 866-970-2435, ext 102 > >> > > > >> > > > >> > > > > --------------------------------------------------------------------- > >> > > To unsubscribe, e-mail: [email protected] > >> > > For additional commands, e-mail: [email protected] > >> > > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [email protected] > >> > For additional commands, e-mail: [email protected] > >> > > >> > -- > >> > Baptiste <Batmat> MATHUS - http://batmat.net > >> > Sauvez un arbre, > >> > Mangez un castor ! > >> > nbsp;! > >> > <[email protected]> > >> > <[email protected]> > >> > > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
