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

111–120 of 172 posts

Re: Why I Moved Back from Gradle to Maven

#111

Post by pjmlp »

kodablah wrote: post #26
bsder wrote: post #17

Earlier quoted context omitted.

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 archite…

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

It is true for us.

If it wasn't forced upon us for Android dev no one at my employer would even bother to learn what is Gradle.

The opinion is that it is the last spot keeping Groovy alive.

Re: Why I Moved Back from Gradle to Maven

#112

Post by pjmlp »

lmilcin wrote: post #47
bsder wrote: post #17

Earlier quoted context omitted.

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 archite…

While all Android Studio users are forced to use Gradle only handful will ever need anything more than the basic boilerplate generated by Studio. My Android projects are mostly private stuff but I don't remember any project that would require any kind of custom build. There is whole plethora of tools. My own calculators for various stuff, app to communicate with my family, apps to manage my electronics (bluetooth, wi…

Try to integrate NDK builds or follow up on the continuous suggestions given at any major Android conference about how to speed up builds.

That basic boilerplate is no longer enough and tricks change with each release.

Re: Why I Moved Back from Gradle to Maven

#113

Post by flukus »

Pxtl wrote: post #95
freedomben wrote: post #81

Earlier quoted context omitted.

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.

Maybe combine a generic non-language specific build system (some variant of Make without the C obsession?) as the outer wrapper around a very language-oriented and inflexible/opinionated build system?

> some variant of Make without the C obsession

Make doesn't have a C obsession (although the docs do), make works anywhere you have a dependency graph that can be expressed as a file timestamp. Here's an example compiling a c# project: http://flukus.github.io/rediscovering-make.html . It's much simpler than any .net build tool (and I've tried them all).

Re: Why I Moved Back from Gradle to Maven

#114

Post by solatic »

jillesvangurp wrote: post #52

I've used both; ant as well in the distant past. More gradle than maven lately but I still have a few maven projects. True for both is that you don't want to push them beyond simple stuff. It just gets ugly and most of your team will look the other way when it is time to sit down and fix the build (usually that job lands in my lap). There are maven and gradle plugins for just about everything and it is tempting to us…

> I let it take care of downloading the jdk, gradle/mvn, and then let it download the world as a separate docker layer before letting it build the software.

Including your source code inside your Docker image unnecessarily inflates the size of your Docker image, including (seemingly from your description) the entire version control history. For big projects (especially big projects where junior engineers didn't get the memo that you shouldn't check binary files into Git...), this can easily add hundreds of megabytes if not gigabytes to the size of the image.

Docker isn't a build system (which is responsible for the creation of both inflated-but-easily-debuggable as well as optimized-for-production), it's a combined packaging system and runtime.

Re: Why I Moved Back from Gradle to Maven

#115

Post by chvid »

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?

It is a bit like explaining zen but I will try.

A programming tool has a certain affordance. It talks to the programmer and says "hey - here is how you use me".

Maven says: Hello. I am a just a configuration file. Just put your project's name and the dependencies in here and the defaults will take of the rest. You remember Ant? Please don't turn this into a big mess.

Gradle says: Oi buddy. I am a full-fledged scripting language. Anything Maven can do? I can do the same times 10. Plus my syntax is tight - just look at this &#€#"&/+=+++ You see the cool kids over there? They all have advanced build scripts with code generation, variable substitution, dsls, database migration, performance daemons. You need this too (unless you are one of those corporate XML-dorks ... yuck XML, it sucks, no one uses XML anymore).

And because we are so cool, we change all the time so you better keep these random files we generate for you under version control: gradle/*, gradlew, gradlew.bat besides your actual build script.

Re: Why I Moved Back from Gradle to Maven

#116

Post by solatic »

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…

If you want ideas, you should check out Ratpack (a web framework for Groovy or Java) and the way the Ratpack.groovy DSL looks.

* Convention over configuration: implicit defaults for everything so the hello world example is very simple. If you try to create a new Java project in Gradle, not by copying and pasting or having the IDE autogenerate something for you, you're going to have a bad time. * Whenever you do want to add something, there is a clear place within the structure of the root ratpack{} closure to add it. The port goes under serverConfig, routes go under handlers, etc. You don't set the port under the routing handlers, that would make no sense. Very different than build.gradle which feels like a flat list of unrelated tasks. * Support for both anonymous code and for code which has been factored out. Of course Gradle supports this (factoring out buildscript dependencies instead of a flat build.gradle) but the experience makes you feel like you're playing around with Frankenstein's monster so hardly anybody ever does so. * Documentation provides examples through tests, which clearly show both the code and the expected outcome, and which Ratpack prioritized being able to express in a concise manner precisely so that it could be used for documentation purposes.

Could Ratpack have gotten rid of the root ratpack{} closure, the serverConfig and handlers and registry closures? Technically yes, they're not needed to namespace their children. But it would be so much less understandable.

Re: Why I Moved Back from Gradle to Maven

#117

Post by pjmlp »

djsumdog wrote: post #100

I've used Maven, Gradle and SBT in major commercial projects. I don't understand this Maven love honestly. Maybe everything I had to work on was just setup incorrectly, but the horrid overly verbose xml configuration files combined with the fact that maven constantly recompiled things it didn't need to and was sooo slow. I think the only good thing from Maven was the directory structure layout (src/{main,test}/{java,…

We love it, because not everyone suffers from XML allergy, which is way more toolable and easily integrated into IDEs than tools using the programming language of the day.

Ant and Maven just work on IDEs and on Netbean's case, they are even the official project format.

Re: Why I Moved Back from Gradle to Maven

#118

Post by pjmlp »

wst_ wrote: post #109
chii wrote: post #90

Earlier quoted context omitted.

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

How that's different in Gradle?

You are actually programming in Groovy, with all the plus and minus it entails.

Regarding the execution speed, IDEs not able to autocomplete, no guarantees about the format that IDEs can easily parse, and it often breaks between releases.

Then to compensate for lack of speed, you need to have a running daemon and an in-memory build cache.

Re: Why I Moved Back from Gradle to Maven

#119

Post by pjmlp »

dljsjr wrote: post #21
derriz wrote: post #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…

The integration with IDEA and Eclipse for Gradle is actually quite good, the only downside is that it's "one-way". That is to say that you can't use the IDE's GUI to configure your build. Gradle enables this as a first-class citizen by providing a "Tooling API": https://docs.gradle.org/current/userguide/embedding.html I know that Buildship, the Eclipse plugin that integrates Gradle, is actually worked on pretty heavi…

It is still not as good as Ant and Maven support, which allow two ways, and are even the project formats used by Netbeans.

Re: Why I Moved Back from Gradle to Maven

#120

Post by pjmlp »

sidlls wrote: post #34
ynezz wrote: post #20

> Gradle features: Great Performance Did I missed the sarcasm tone? I've never experienced slower build systems then those used in Java world, like Gradle for example.

People complain about C and C++ compile times but they don't hold a candle to that in Android-Java-land in my experience.

Yep, specially when you get to join NDK and Gradle builds.

It is not time for coffee, rather lunch.

Post reply on HN