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

61–70 of 172 posts

Re: Why I Moved Back from Gradle to Maven

#61

Post by Macha »

lmm wrote: post #30
eecc wrote: post #13

Maven’s approach is a lost cause: you either expect any user to coerce their case into your model (and hope the plugin is documented, dependencies work (bwahahaha) and is maintained) or you breakout to some exec plugin and give up on platform agnostic builds. Sure, it’s an unforgiving ambition and many other systems fell trying, but it was their choice. With Gradle the blame falls squarely at the feet of plugins, and…

> you either expect any user to coerce their case into your model (and hope the plugin is documented, dependencies work (bwahahaha) and is maintained) I find all the cases can be coerced, and it's not even hard. Some users seem to insist on customization for its own sake, "oh I absolutely must call my source folder source rather than src", but Maven does the right thing by ignoring those users, with the result that y…

The case I remember was a couple of years ago. We had a test runner for our JS code that was delivered by our Java webapp. Part of that configuration was the list of flags to a maven plugin. The issue was that we had two orthogonal configuration options that affected the list of flags. Initially, it used HTMLUnit and didn't record coverage statistics. We wanted to record coverage, and also switch to PhantomJS (when it was new) over HTMLUnit. Our test times were as follows:

PhantomJS - 1 min

PhantomJS + Coverage - 5 min

HTMLUnit - 10 min

HTMLUnit + Coverage - 25min

Coverage required one set of additional flags, PhantomJS required another. But we could only replace the test runner string, not add to it. We couldn't drop HTMLUnit altogether, as our company mandated CI system would not make it easy to install PhantomJS. And tests were still new to many team members so if we defaulted coverage on, nobody would run it with those times. So ideally we'd have mvn test -Pphantomjs -Pcoverage if we wanted phantom with coverage. But actually we had to do mvn test -P{phantomCoverage,htmlUnitCoverage,phantomNoCoverage,htmlUJnitNoCoverage} which meant copy pasting a substantial chunk of our pom file 4 times to change two lines of it, rather than a base case with two overrides.

Re: Why I Moved Back from Gradle to Maven

#62

Post by kodablah »

na85 wrote: post #60
kodablah wrote: post #45

Earlier quoted context omitted.

> needs to stop the whole convention-over-configuration idea Yup, and while we're at it, realize that the declarative approach doesn't work after the first basic uses and even though your hello world build file is simple, most people need customization. Scripting the build system should be its main feature and everything else as just shortcuts (to be fair, Gradle kinda does this w/ tasks, but doesn't make it simple t…

This may be naive but doesn't GNU Make tick all these boxes in addition to being ubiquitous?

Not ubiquitous and missing shortcuts. How do you compile 5 JVM projects in different JVM languages, sharing different configured sets of potentially hundreds of libraries across the classpath and make sure there are no versioning conflicts? Shortcuts are required, they just don't need to hide everything.

Re: Why I Moved Back from Gradle to Maven

#63

Post by jillesvangurp »

lmm wrote: post #25
rhacker wrote: post #4

I spent a good 18 years in the Java coding stack. I adopted Maven when they just released version 2 and watched one of its evangelists talk at a JavaOne. Obviously now it's insane to think about a programming language that doesn't have a dependency manager (even C/C++ has Conan!). After a long time fighting between what I liked best between Maven or Gradle I realized that the only thing I really needed was the parts…

> Now we simply have bash scripts that do all our one-offs that often were nightmares to accomplish in Gradle or Maven. Whether it is JAXB or Docker integration every maven/gradle plugin I ever used was 10 times harder than just bash. This is the opposite of my experience. Trying to get consistent behaviour out of bash scripts is a nightmare (every nontrivial bash script has an undocumented dependency on a particular…

Funnily, 10 times harder is exactly my experience with most maven plugins. Maven is fine if you stick to compile, test, and jar. Anything beyond that just tends to escalate into madness.

Re: Why I Moved Back from Gradle to Maven

#64

Post by commandlinefan »

acrive wrote: post #24

Because you don't know Groovy. Simple. Maven it's only in your comfort zone. Bye.

Not really - or, at least, not that simply. When my last organization moved to Gradle, and we had a Gradle ninja go in and migrate all of our build scripts to hundreds of lines of Gradle scripts, I thought the same thing. So I spent a month on-and-off studying and learning base Groovy (fending off coworkers who would pass by my desk and ask, "what are you doing?" "Learning Groovy" "Why are you learning groovy?" "So I can use Gradle" "Why do you have to learn Groovy to use Gradle, Gradle Ninja already did it for you"). I finally got to where I was, if not an expert, at least comfortable with core Groovy. But even then, there was a lot more to Gradle than just "a build script written in Groovy" - there's another learning curve to climb once you've learned Groovy.

Re: Why I Moved Back from Gradle to Maven

#65

Post by kovrik »

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…

For me the main difference between Maven and Gradle is the way I read them.

Maven is declarative. Yes, it has some boilerplate, it may not look nice (I'm not a big fan of XML), but the main advantage for me is that I can read it easily and understand what it does. Because it just declares tasks. Similar to any other XML file or JSON or .properties. You just read it.

Reading Gradle, on the other hand, is more like reading a program. You can't just read it, you have to interpret it, you need to put effort in order to understand what this program does.

Yes, Gradle may be more flexible and less boilerplate, but personally I don't want to have another program (in another language) to just build my project.

Re: Why I Moved Back from Gradle to Maven

#66

Post by na85 »

kodablah wrote: post #62
na85 wrote: post #60

Earlier quoted context omitted.

This may be naive but doesn't GNU Make tick all these boxes in addition to being ubiquitous?

Not ubiquitous and missing shortcuts. How do you compile 5 JVM projects in different JVM languages, sharing different configured sets of potentially hundreds of libraries across the classpath and make sure there are no versioning conflicts? Shortcuts are required, they just don't need to hide everything.

I guess I'd compile them like anything else: using Make to invoke the compiler.

Checking versions can be accomplished by using awk or another tool to compare output from $compiler --version.

What am I missing?

Re: Why I Moved Back from Gradle to Maven

#67

Post by xienze »

bitcharmer wrote: post #48
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…

I'm neither Maven nor Gradle ninja. Just a senior software developer with 15+ years of experience... > Maven requires a lot of boilerplate for everything. Copy-paste I think you may be doing it wrong. Maven supports declaring project-wide or module-wide entities and their attributes at every level. Duplication or copy-paste is a sign of not understanding Maven > Gradle... It's an environment for programmer To me this…

> I think you may be doing it wrong. Maven supports declaring project-wide or module-wide entities and their attributes at every level. Duplication or copy-paste is a sign of not understanding Maven

That, and it sounds like the parent doesn’t understand POM inheritance and archetypes.

Re: Why I Moved Back from Gradle to Maven

#68

Post by kelnos »

lmilcin wrote: post #53
bitcharmer wrote: post #48

Earlier quoted context omitted.

I'm neither Maven nor Gradle ninja. Just a senior software developer with 15+ years of experience... > Maven requires a lot of boilerplate for everything. Copy-paste I think you may be doing it wrong. Maven supports declaring project-wide or module-wide entities and their attributes at every level. Duplication or copy-paste is a sign of not understanding Maven > Gradle... It's an environment for programmer To me this…

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).

Re: Why I Moved Back from Gradle to Maven

#69

Post by kelnos »

bitcharmer wrote: post #48
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…

I'm neither Maven nor Gradle ninja. Just a senior software developer with 15+ years of experience... > Maven requires a lot of boilerplate for everything. Copy-paste I think you may be doing it wrong. Maven supports declaring project-wide or module-wide entities and their attributes at every level. Duplication or copy-paste is a sign of not understanding Maven > Gradle... It's an environment for programmer To me this…

> > Gradle... It's an environment for programmer

> To me this is a counter-argument. When I need to understand project configuration I expect structure, not behaviour.

Agreed. Every time I see a build system that lets you write arbitrary code, I shy away from it. Builds should be standardized, not a mess of custom code. Maven lets you write plugins for the case when you need to do something truly custom, but in my experience that's vanishingly rare.

Re: Why I Moved Back from Gradle to Maven

#70

Post by [deleted] »

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…

[deleted]
Post reply on HN