Live data from Hacker News

Why I Moved Back from Gradle to Maven

blog.philipphauer.de

11–20 of 172 posts

Re: Why I Moved Back from Gradle to Maven

#11
post #6
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…

Honestly, I have the opposite opinion. I really don't like it when there are custom bash build scripts. And you have to figure out how they work and what they do. And how to pass additional parameters etc. If you use Maven for your project, then I expect that if I run `mvn clean install` then it will build the project. I think that is the whole point of standard build tools: that you can switch projects easily, run t…

This is a common problem for programmers in general, not just at build time. Occasionally you will run into a case where the framework you've chosen just doesn't fit. You can try to hammer your need into the framework in some horrific fashion or your can temporarily circumvent it for this one task. Which path you go depends on a lot of factors.

Re: Why I Moved Back from Gradle to Maven

#12
I went back to maven. I had trouble finding solutions to gradle issues when I got stuck. Maven solutions are easier to find. This will probably change as gradle becomes more popular.

I should add that I am no Java guru, so for me this is an important consideration. Still, the real Java gurus at my company are split on the issue. We have projects on both build systems.

Re: Why I Moved Back from Gradle to Maven

#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’re on your own (which has always been the case anyway)

Re: Why I Moved Back from Gradle to Maven

#14
Concur. I found Gradle to be to far removed from the truth so to speak. I like Maven's declarative xml and its promulgation of the build life-cycle. This makes a complex build easier to maintain in the long run imo.

Re: Why I Moved Back from Gradle to Maven

#16
I delivered a session at JavaOne (2001?) on Ant (I was a whiz at it). Then, I had to learn Maven as it gained traction. I'm currently doing Android development, but I'm a little embarrassed to say that I don't really grok Gradle the way I do with Ant and Maven. I don't have anything against Gradle. I just don't want to spend another minute of my life learning another Java build tool. So, I stick to the Gradle defaults when creating a new project in Android Studio, and rely on SO and whatnot whenever I need to customize. Haven't been burned yet.

Re: Why I Moved Back from Gradle to Maven

#17

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…

Fix the documentation!

Focus on Android Studio because that's the only place people really use Gradle because they are forced to do so.

You need to create a LOT of Android Studio sample projects, and they need to be kept up to date for the various versions of Android Studio. If you did nothing but create "Hello World" in a zillion various flavors (Java, Kotlin, Scala, NDK, NDK with static library on different architectures, etc.) for people, that would be huge.

My specific beef is with NDK projects. Pulling in static libraries and compiling them with the NDK is a mix of magical keywords that sometimes materialize from some kind stranger via chat--generally because Gradle has to shove those keywords to something like CMake--which ALSO has an enormous learning curve.

Re: Why I Moved Back from Gradle to Maven

#18
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…

I do something similar but with a Makefile as the top level. Every project I work on has a top level default that will fetch dependencies and build the project.

Lower level recipes are either one liners that invoke a project specific builder (ex: mvn package) or they invoke a separate bash script.

For complicated polyglot projects it works great as each component can use its own native tooling yet the top level is consistent.

Re: Why I Moved Back from Gradle to Maven

#19
I can see the attraction in a build system based on a proper full featured programming language but I've never been tempted to try gradle because I believe the approach has a fundamental flaw. I.e. that it's impossible for IDEs to reliably extract useful project structure from the build description.

Even as a 25 year vi/vim user, I've succumbed to depending on IDEs more and more and I believe that any proposed build system has to easily support deep/rich integration with IDEs. This is theoretically impossible if the build system is effectively a general Turing-complete programming language. At best you will be able to provide brittle integration or else the IDE will have to dumbly treat the entire build process as a black box.

Post reply on HN