Live data from Hacker News

Why I Moved Back from Gradle to Maven

blog.philipphauer.de

31–40 of 172 posts

Re: Why I Moved Back from Gradle to Maven

#31

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…

The key point that Gradle needs to make clearer is to delineate between task creation and task execution and which code is running where. It is very confusing for people to know whether their code is going to execute at gradle file load or at task execution. People get confused that they can't just use the result of one task when setting the opts for another. Edit: Also, I personally do the opposite route wrt the par…

Definitely agree with this. The Gradle lifecycle and the difference between Task Execution and Build Configuration is not intuitive at all. Neither is the fact that when you just stick a `<<` or `doLast()` in there without understanding why, it works with some tasks and not with others (killing << is a step in the right direction but making the build lifecycle more understandable would be hugely helpful).

Re: Why I Moved Back from Gradle to Maven

#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 idea how many shellscript-infested build setups I've seen for C programs that could easily have been built using entirely standard Makefiles. If the author had bothered learning to use Makefiles.

Re: Why I Moved Back from Gradle to Maven

#33
post #3

This pretty much matches my experience. I resisted maven and the obscure pom.xml structure for a long time but eventually came around due to its excellent dependency management. Now that I understand maven it's hard to see how Gradle really improves on maven for basic Java projects.

Seems "obscure", but it has a schema.

Just to be clear, I'm not against XML at all. Maven does more but can be a pain to program compared to older systems like ant, which is also XML-based. Configuring plugins to fire at the right point in the build cycle (e.g., package vs. install) comes lightly to mind.

It's gotten a lot better because there are many examples now accessible with Google. Overall I'm pretty happy with maven now. It works.

Re: Why I Moved Back from Gradle to Maven

#34
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.

Re: Why I Moved Back from Gradle to Maven

#35
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.

Are you talking about Android? I'm using Gradle for traditional Java projects (standalone and web) and its performance was good, similar to Maven. I agree that Android plugin is very slow, but I think that it's not a Gradle to blame.

Re: Why I Moved Back from Gradle to Maven

#36
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.

Gradle is objectively faster than Maven. Android projects suffer heavily due to multidexing.

Re: Why I Moved Back from Gradle to Maven

#37

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.

Re: Why I Moved Back from Gradle to Maven

#38
post #27
post #24

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

Gradle scripts are an undocumented superset of Groovy. It's not just Groovy, it's the fact that there's no consistent way to know what settings and defaults come from where. (And really, why would you know Groovy these days? Is it even used for anything outside of Gradle anymore?)

* Easy to read * Collections tools * Functional programming with closure * Traits * Typed or not * DSL * 100% compatibility with all jars * Awesome framework like Grails and the upcoming Micronaut and SpringBoot * Enterprise software or script, you're welcome.

There is a whole world out there.

Re: Why I Moved Back from Gradle to Maven

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

Idea works fine with non-trivial Gradle builds. It might be theoretically impossible, but on practice it works.

Re: Why I Moved Back from Gradle to Maven

#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 less powerful.

Post reply on HN