Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Moved Back from Gradle to Maven

blog.philipphauer.de

Post reply on HN
Print view View original

81–90 of 172 posts

Re: Why I Moved Back from Gradle to Maven

#81

Post by freedomben »

kodablah wrote: post #57
bborud wrote: post #32

Flexibility is not something I want in a build system. I want predictability and simplicity. "Flexibility" just means that the dumbest guy on the project will find sufficient rope to hang the whole team sooner or later. That being said, "flexibility" is not special to Gradle. As long as there have been build systems there have been people who are too lazy to learn them and get "bright ideas". For instance I have no i…

> Flexibility is not something I want in a build system. [...] "Flexibility" just means that the dumbest guy on the project will find sufficient rope to hang the whole team sooner or later. We're on opposite sides here. I can control my team wrt rope and what not. But it's very hard to wrangle a build system to perform some advanced task you need without flexibility. I'd way rather have problems with the build system…

I agree. With an inflexible build system we still end up with the nasty shell script but it's worse because it wraps the build system.

Re: Why I Moved Back from Gradle to Maven

#82

Post by acdha »

bborud wrote: post #32

Flexibility is not something I want in a build system. I want predictability and simplicity. "Flexibility" just means that the dumbest guy on the project will find sufficient rope to hang the whole team sooner or later. That being said, "flexibility" is not special to Gradle. As long as there have been build systems there have been people who are too lazy to learn them and get "bright ideas". For instance I have no i…

> "Flexibility" just means that the dumbest guy on the project will find sufficient rope to hang the whole team sooner or later.

In my experience, it's not dumb but clever which you should worry about — those are the ones who'll spend two weeks making something completely unmaintainable after reading someone's post about how some esoteric mathematically pure style delivered a 7% performance increase on an edge case.

Re: Why I Moved Back from Gradle to Maven

#83

Post by ataturk »

Boxxed wrote: post #37
wendelinsky wrote: post #10

Yo, new Gradle developer experience lead here. I fully empathize that it's much too difficult to wrap one's head around Gradle, so I want to share some things you might find interesting: * The Gradle Kotlin DSL, which is nearing production-readiness, substantially improves the assistance/docs one gets through the IDE. * However, the Kotlin DSL does not help with the large API surface and understanding of Gradle conce…

Personally, I think Gradle (and a whole lot of other software) needs to stop the whole convention-over-configuration idea. It makes things way too difficult to debug and learn from, all to save some one-time typing. Making everything implicit for the sake of simplicity is really just the opposite.

Um, no. Because Maven and Gradle share the concept of convention over configuration and you obviously weren't around for the bad old days of ant (or make) in which every company had their own weird builds.

I used Gradle for years and then in my current role had to move back to Maven because that's what my employer wants and I don't miss Gradle. I was quite good at creating builds with Gradle, too.

But I must concede that the points people make about it are accurate--you can't depend on having just one Gradle guru on the team and there is a lot of magic with Gradle whereas Maven is much more clear what is going on and how. Also, the point about "build flexibility"--it just doesn't come up that much. You can write shell scripts you know. I did once have a Gradle build that would install SQL Server, install our application, run all the tests, including integration tests against the live database, then tear everything down and remove it all like it was never there.

I am interested in the Gradle Kotlin DSL since I also have had to accept the fact that Groovy is dying/dead now. Outside of IDEA, you can't get good Groovy IDE support anymore for example. It's dead, Jim. Kotlin lives, albeit with a sliver of market share thanks mostly to Android and the tireless efforts of JetBrains.

Re: Why I Moved Back from Gradle to Maven

#84

Post by orbitur »

kelnos wrote: post #68
lmilcin wrote: post #53

Earlier quoted context omitted.

It may be you are doing plain simple (can be large, but still simple) projects for which Maven is perfectly fine. Gradle is for when you require some more complicated behaviour in your project. For example in my current project the applications are packaged into completely custom and proprietary package that is then being used by the completely custom automation to be deployed to the infrastructure. I have created a…

> For example in my current project the applications are packaged into completely custom and proprietary package that is then being used by the completely custom automation to be deployed to the infrastructure. If you really need something insanely custom, you can just write a maven plugin (it's actually really easy to do so).

Not as easy as using gradle. I've written a couple maven plugins in my time, and I'm so very glad we have gradle now.

Re: Why I Moved Back from Gradle to Maven

#85

Post by orbitur »

chapill wrote: post #80
lmilcin wrote: post #43

I moved from Maven to Gradle about two years ago and I am not going to look back. I understand the arguments made in article and I am the Gradle ninja in my project so I may have subjective view on the whole topic. My points: - Maven requires a lot of boilerplate for everything. Copy-paste. I need to instruct everybody on what to copy, where to paste, and how to edit and what they should not touch under any circumsta…

>Gradle... It's an environment for programmer! >Maven...you have to write your own plugin. Not nice. >If I wanted to change one thing in Gradle it would be for the Gradle project to focus on debugging You've just explained why I have no interest in Gradle. You're writing one off, undocumented, anonymous plugins, in a weird domain specific language, with debugging tools that aren't very good. Worse, when the Gradle gu…

This sounds like a process problem, not a gradle problem. I don't think there's inherent readability to maven, and I'd love to share my previous employer's pom files with you.

Re: Why I Moved Back from Gradle to Maven

#86

Post by jryan49 »

kodeninja wrote: post #77

Probably unrelated, but Java really needs to fix its Classpath Hell issues. On so many sufficiently large Java projects, you end up descending into the inclusion/exclusion madness with your build files because your app is inheriting `log4j` from 50 different libraries. Or the infamous xerces hell[1]. And fixing that in maven is not pretty :(. [1] https://stackoverflow.com/questions/11677572/dealing-with-xe...

Wasn't Java 9 modules supposed to help address these issues?

Re: Why I Moved Back from Gradle to Maven

#89

Post by chii »

orbitur wrote: post #84
kelnos wrote: post #68

Earlier quoted context omitted.

> For example in my current project the applications are packaged into completely custom and proprietary package that is then being used by the completely custom automation to be deployed to the infrastructure. If you really need something insanely custom, you can just write a maven plugin (it's actually really easy to do so).

Not as easy as using gradle. I've written a couple maven plugins in my time, and I'm so very glad we have gradle now.

Maven plugins still have lots of structure to obey, but you can treat the plugin as a black box very easily. Other people dont need to understand the innards to compose the plugin with other plugins.

I'd be hard-pressed to see how you can do that with gradle.

Re: Why I Moved Back from Gradle to Maven

#90

Post by chii »

andrewmcwatters wrote: post #56
chvid wrote: post #40

I have been a user of make, Ant, Maven and Gradle. And Grunt, Gulp and now npm + webpack in the JavaScript-world. And of all these Maven is by far the better build tool. To the creator of these tools: Try to remember that what you are creating is a support tool. A second act to the main development language. It is better if it is not general purpose, it is better if it is not turing complete, it is better if it is le…

I don't spend a whole lot of time in the Java world, just enough to take care of small requests. So, I've only experienced maybe half of those. Could you explain a few killer reasons why Maven is the better build tool?

All maven builds are exactly the same (unless they force the tool to do otherwise), and files are always in well known locations.
Post reply on HN