Re: Arguments for Maven vs. Gradle
On Tue, Sep 11, 2012 at 4:33 PM, Graham Leggett wrote: > On 11 Sep 2012, at 10:14 PM, Benson Margulies wrote: > >> I don't think it's useful to debate build tools and their builders or >> tools on this list. > > I believe it is very useful. Many new users to maven don't fully understand > the problem maven tries to solve, and a discussion like this one will > hopefully shed more light on why maven approaches the build problem as it > does. My personal opinion is that any valuable light is overwhelmed by all the heat. However, as I seem to be unusual in holding this opinion, I climb back under my bridge. > > Regards, > Graham > -- > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Arguments for Maven vs. Gradle
Am 11.09.2012 22:59 schrieb "Arnaud Héritier" : > > I find also such discussion interesting > it is always good to know what is existing arround and if some inputs may > drive to improve Maven itself. > The fact to know also why Maven is here is an important thing to better us > it. > This is especially what we did with Nicolas De loof in our French book few > years ago and readers loved a lot because they were able to understand why > some choices were done in maven .. > > About Gradle, I studied it and tries to use it but for now I'm always not > convinced about its ideology. I like to be free of my choices but I'm not > sure that it is always a good thing. Standardization may be seen as a > limitation but for whom ? For the team using it ? For people who will join > later the project and will find something known ? For the transversal team > in a company that will support dev teams ? Depending of the context, the > "enforced" standardisation may be a good thing. I'm sure that a gradle > build in experts hands may be magical but how often will it be the case and > for how many times ? > > What is fun is that this debate Gradle vs Maven makes me think to the > debate Git vs SVN we have on the dev list. Me too. > What do we prefer ? Something > powerful but perhaps to not put in all hands ? Or a common tool that is > just doing the job ? A tool which makes it likely that we achieve our goals easily. What are our goals? * issue control about what people do with maven source code? * ensure plugin users know where their feedback should be sent to or where to get help? How can this be done without interfering with other goals? * Make contributing as easy as possible? If so: who are our potential new contributors? Which tools do they like to use? * Learn about what our users need? What other ways of doing this could be advantageous, besides jira? > > Arnaud > > > On Tue, Sep 11, 2012 at 10:33 PM, Graham Leggett wrote: > > > On 11 Sep 2012, at 10:14 PM, Benson Margulies wrote: > > > > > I don't think it's useful to debate build tools and their builders or > > > tools on this list. > > > > I believe it is very useful. Many new users to maven don't fully > > understand the problem maven tries to solve, and a discussion like this one > > will hopefully shed more light on why maven approaches the build problem as > > it does. > > > > Regards, > > Graham > > -- > > > > > > > -- > - > Arnaud Héritier > 06-89-76-64-24 > http://aheritier.net > Mail/GTalk: aherit...@gmail.com > Twitter/Skype : aheritier
Re: Arguments for Maven vs. Gradle
I find also such discussion interesting it is always good to know what is existing arround and if some inputs may drive to improve Maven itself. The fact to know also why Maven is here is an important thing to better us it. This is especially what we did with Nicolas De loof in our French book few years ago and readers loved a lot because they were able to understand why some choices were done in maven .. About Gradle, I studied it and tries to use it but for now I'm always not convinced about its ideology. I like to be free of my choices but I'm not sure that it is always a good thing. Standardization may be seen as a limitation but for whom ? For the team using it ? For people who will join later the project and will find something known ? For the transversal team in a company that will support dev teams ? Depending of the context, the "enforced" standardisation may be a good thing. I'm sure that a gradle build in experts hands may be magical but how often will it be the case and for how many times ? What is fun is that this debate Gradle vs Maven makes me think to the debate Git vs SVN we have on the dev list. What do we prefer ? Something powerful but perhaps to not put in all hands ? Or a common tool that is just doing the job ? Arnaud On Tue, Sep 11, 2012 at 10:33 PM, Graham Leggett wrote: > On 11 Sep 2012, at 10:14 PM, Benson Margulies wrote: > > > I don't think it's useful to debate build tools and their builders or > > tools on this list. > > I believe it is very useful. Many new users to maven don't fully > understand the problem maven tries to solve, and a discussion like this one > will hopefully shed more light on why maven approaches the build problem as > it does. > > Regards, > Graham > -- > > -- - Arnaud Héritier 06-89-76-64-24 http://aheritier.net Mail/GTalk: aherit...@gmail.com Twitter/Skype : aheritier
Re: Arguments for Maven vs. Gradle
On 11 Sep 2012, at 10:14 PM, Benson Margulies wrote: > I don't think it's useful to debate build tools and their builders or > tools on this list. I believe it is very useful. Many new users to maven don't fully understand the problem maven tries to solve, and a discussion like this one will hopefully shed more light on why maven approaches the build problem as it does. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: Arguments for Maven vs. Gradle
I don't think it's useful to debate build tools and their builders or tools on this list. On Tue, Sep 11, 2012 at 3:26 PM, Anders Hammar wrote: >> If they bring their ideas here, they usually get the kind of advice that >> leads to good practices. > > Well, the problem is that they don't go here. They just happily go on > trying to invent the wheel (but a square one). > > /Anders > >> They also have to frame their questions at the goal level rather than the >> technical level. >> My only concern is that sometimes the experts here get into the technical >> solution before asking about the goal. >> As you point out, Maven can be made to do many things that should not be >> done. It is hard to do but there is enough expertise in this forum to make >> it happen. >> >> >> Ron >> >>> >>> /Anders >>> >>> On Tue, Sep 11, 2012 at 7:45 PM, Graham Leggett wrote: On 11 Sep 2012, at 7:22 PM, Curtis Rueden wrote: >> 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. A finicky build is a symptom of poor design, and if your design is poor no tool, unit test, CI, package, strategy or methodology is going to compensate for it. Discipline is the art of knowing why not to do something, and is a difficult thing to teach. There is a tremendous amount of waste that is perpetrated in software engineering, software is built to be disposable, with very short shelf lives. Maven challenges this trend by encouraging convention, repeatability, and code longevity, and this is a very good thing. Regards, Graham -- >>> - >>> 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 > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Arguments for Maven vs. Gradle
> If they bring their ideas here, they usually get the kind of advice that > leads to good practices. Well, the problem is that they don't go here. They just happily go on trying to invent the wheel (but a square one). /Anders > They also have to frame their questions at the goal level rather than the > technical level. > My only concern is that sometimes the experts here get into the technical > solution before asking about the goal. > As you point out, Maven can be made to do many things that should not be > done. It is hard to do but there is enough expertise in this forum to make > it happen. > > > Ron > >> >> /Anders >> >> On Tue, Sep 11, 2012 at 7:45 PM, Graham Leggett wrote: >>> >>> On 11 Sep 2012, at 7:22 PM, Curtis Rueden wrote: >>> > 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. >>> >>> A finicky build is a symptom of poor design, and if your design is poor >>> no tool, unit test, CI, package, strategy or methodology is going to >>> compensate for it. Discipline is the art of knowing why not to do something, >>> and is a difficult thing to teach. >>> >>> There is a tremendous amount of waste that is perpetrated in software >>> engineering, software is built to be disposable, with very short shelf >>> lives. Maven challenges this trend by encouraging convention, repeatability, >>> and code longevity, and this is a very good thing. >>> >>> Regards, >>> Graham >>> -- >>> >> - >> 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
Re: Arguments for Maven vs. Gradle
On 11/09/2012 2:51 PM, Anders Hammar wrote: I'd just like to add that although Maven encourages convention over configuration etc etc, it will by no means by itself ensure that you get good build "scripts" (poms aren't scripts, but I think you know what I mean). I've seen so many weird/strange/bad/fascinating solutions incorporated into customers' Maven builds. Possibly, it is a problem that too many people think that Maven by itself will give you good standard builds that they don't worry about having just about anyone go hack the poms. If they bring their ideas here, they usually get the kind of advice that leads to good practices. They also have to frame their questions at the goal level rather than the technical level. My only concern is that sometimes the experts here get into the technical solution before asking about the goal. As you point out, Maven can be made to do many things that should not be done. It is hard to do but there is enough expertise in this forum to make it happen. Ron /Anders On Tue, Sep 11, 2012 at 7:45 PM, Graham Leggett wrote: On 11 Sep 2012, at 7:22 PM, Curtis Rueden wrote: 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. A finicky build is a symptom of poor design, and if your design is poor no tool, unit test, CI, package, strategy or methodology is going to compensate for it. Discipline is the art of knowing why not to do something, and is a difficult thing to teach. There is a tremendous amount of waste that is perpetrated in software engineering, software is built to be disposable, with very short shelf lives. Maven challenges this trend by encouraging convention, repeatability, and code longevity, and this is a very good thing. Regards, Graham -- - 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
Re: Arguments for Maven vs. Gradle
I'd just like to add that although Maven encourages convention over configuration etc etc, it will by no means by itself ensure that you get good build "scripts" (poms aren't scripts, but I think you know what I mean). I've seen so many weird/strange/bad/fascinating solutions incorporated into customers' Maven builds. Possibly, it is a problem that too many people think that Maven by itself will give you good standard builds that they don't worry about having just about anyone go hack the poms. /Anders On Tue, Sep 11, 2012 at 7:45 PM, Graham Leggett wrote: > On 11 Sep 2012, at 7:22 PM, Curtis Rueden wrote: > >>> 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. > > A finicky build is a symptom of poor design, and if your design is poor no > tool, unit test, CI, package, strategy or methodology is going to compensate > for it. Discipline is the art of knowing why not to do something, and is a > difficult thing to teach. > > There is a tremendous amount of waste that is perpetrated in software > engineering, software is built to be disposable, with very short shelf lives. > Maven challenges this trend by encouraging convention, repeatability, and > code longevity, and this is a very good thing. > > Regards, > Graham > -- > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Arguments for Maven vs. Gradle
On 11 Sep 2012, at 7:22 PM, Curtis Rueden wrote: >> 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. A finicky build is a symptom of poor design, and if your design is poor no tool, unit test, CI, package, strategy or methodology is going to compensate for it. Discipline is the art of knowing why not to do something, and is a difficult thing to teach. There is a tremendous amount of waste that is perpetrated in software engineering, software is built to be disposable, with very short shelf lives. Maven challenges this trend by encouraging convention, repeatability, and code longevity, and this is a very good thing. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: Arguments for Maven vs. Gradle
On Sep 11, 2012, at 8:22 PM, Curtis Rueden wrote: > 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. Kind of roaming away from Maven v. Gradle, but a process that I've grown comfortable with in large groups is a) locking all the POMs for anyone who's not a "POM mentor", b) buddying everyone else with a mentor to submit their changes, and c) anyone starting a new subproject project gets full access to their own POM for the life of their project. This tends to lessen POM damage as mentors take responsibility for their mentees, causes mentees to think harder about whether they really need a POM change to move forward (they learn it's certainly more expedient if they don't!), but still allows folks entrusted to create new modules the freedom to roam, make mistakes with projects that are not part of the mainline build yet, and generally get experience with POMs that they wouldn't get with patches alone. Other tweaks are possible, such as having mentors being required to talk to architects for certain classes of changes (such as dependency changes). Note that dependency changes can also be managed by locking down a repository manager and disabling auto downloading. Brian - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Arguments for Maven vs. Gradle
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 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 > > To: Maven Users List > > 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 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 > >> > >> > > -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 > >> > &
Re: Arguments for Maven vs. Gradle
Oki, I confess... hang me now "line on the left, only one cross each person" ;) LieGrue, stru - Original Message - > From: "Thiessen, Todd (Todd)" > To: Maven Users List ; Mark Struberg > > Cc: > Sent: Tuesday, September 11, 2012 2:35 PM > Subject: RE: Arguments for Maven vs. Gradle > >> "With great power comes great responsibility" (Starwars? Kung-fu > panda? >> not sure anymore :) > > Spiderman. Come on now... You get points for maven knowledge but minus points > for missing the Spiderman reference. Three cheers for Stan Lee ;-). > > - > 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
RE: Arguments for Maven vs. Gradle
> "With great power comes great responsibility" (Starwars? Kung-fu panda? > not sure anymore :) Spiderman. Come on now... You get points for maven knowledge but minus points for missing the Spiderman reference. Three cheers for Stan Lee ;-). - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Arguments for Maven vs. Gradle
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 > To: Maven Users List > 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 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 >> >> > > -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 ad
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 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 > > > > -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 MATHUS - http://batmat.net > > Sauvez un arbre, > > Mangez un castor ! > > nbsp;! > > > > > > >
Re: Arguments for Maven vs. Gradle
(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 > > -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 MATHUS - http://batmat.net > Sauvez un arbre, > Mangez un castor ! > nbsp;! > > >
RE: Arguments for Maven vs. Gradle
> -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
Re: Arguments for Maven vs. Gradle
On Sep 10, 2012, at 4:15 AM, Graham Leggett wrote: > On 9 Sep 2012, at 22:20, "KARR, DAVID" wrote: > >> 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. > > This to me is the fatal flaw in ant and all tools like it. Ant allows the > developer to do whatever they like, and so they do, unnecessarily different > to everyone else, and this difference must be debugged, documented and > learned, over and over again, wasting countless hours and money. > > In contrast, Maven represents discipline. > > To understand maven one first has to understand discipline in software > engineering, why there is no value in solving a solved problem in a way that > is different but no better than solutions that have gone before. Why the best > documentation is simply no documentation at all. Why the gift of a repeatable > build is priceless to the person who has to fix a bug under stressful > conditions. Well said by Ron and Graham. With the knowledge as the person that wrote the "associated Maven build" (shameless plug ;) and without disclosing anything, I think you can see based on it's dependencies that it's not going away anytime soon. There was a lot of resistance to it in the first place, to the point that I was seriously asked a few times why the build couldn't be ported to Ant. What that says to me is there is a lot of organizational inertia around not doing the same thing multiple ways. In interviewing stakeholders, nobody was attached to Ant, they just knew it's warts and how to get around. It was a sunk cost. Totally reasonable. Gradle not only allows the same thing to be done multiple ways (like Ant), but now you would be introducing all of Gradle's multiple ways in it's own different way. You'll have one paradigm that is "hard" but can't and won't be removed, one that is almost universally deprecated (I can't remember the last time I've seen a new project using it), and another that is some hybrid of the two, but with completely different syntactic sugar. Given the resistance to adding one new build tool, adding a second for a total of three doesn't sound likely. Also do not forget about plugin support necessary for target environments. I did do the thought experiment at the time why the build could (or should) not be rewritten in Ant (welcome to the world of being a good contractor!), and the final reason Ant couldn't be used was target product plugin support for Ant wasn't there. If you dig into the plugin context that is available when a plugin runs, one wouldn't seriously attempt to run Maven plugins in an Ant build. I theoretically could have ported the plugin(s) to Ant task(s), but one key vendor plugin was proprietary. This same problems will haunt you in Gradle until all vendors have equal support for Gradle as they do for Maven. While I think I only wrote one plugin for that build, such internal plugins can be used in builds across the company. This is another reason to standardize on a single build environment. This isn't to say that you won't need to do some plugin work to get your new build in robust working order. When I did the (now apparently missing) POC of it, I remember that there was some issues that were not solvable with five minutes of Maven foo (and why I stopped working on it). But it wasn't weeks of work either. HTH, Brian - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Arguments for Maven vs. Gradle
On 9 Sep 2012, at 22:20, "KARR, DAVID" wrote: > 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. This to me is the fatal flaw in ant and all tools like it. Ant allows the developer to do whatever they like, and so they do, unnecessarily different to everyone else, and this difference must be debugged, documented and learned, over and over again, wasting countless hours and money. In contrast, Maven represents discipline. To understand maven one first has to understand discipline in software engineering, why there is no value in solving a solved problem in a way that is different but no better than solutions that have gone before. Why the best documentation is simply no documentation at all. Why the gift of a repeatable build is priceless to the person who has to fix a bug under stressful conditions. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Arguments for Maven vs. Gradle
+1 On Sun, Sep 9, 2012 at 5:42 PM, Ron Wheeler wrote: > 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. > > Ron > > > 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-unsubscribe@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-unsubscribe@maven.**apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
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. Ron 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
Arguments for Maven vs. Gradle
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
