Live data from Hacker News

Why I Moved Back from Gradle to Maven

blog.philipphauer.de

41–50 of 172 posts

Re: Why I Moved Back from Gradle to Maven

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

I think it's not correct to say that Turing-completeness somehow prevents extracting project structure. If a build tool can extract that information, why IDE could not do that? In fact this is how Gradle projects are imported into Intellij and Eclipse: Gradle builds project model by running Groovy or Kotlin scripts, and then IDEs are working with declarative model. The real problem is working with scripts themselves: changing them automatically (applying refactorings), providing good completion, navigation, etc. The dynamic nature of Groovy makes it much harder for IDEs to provide good tooling, but even with statically typed Kotlin it is hard because Gradle APIs are very dynamic in nature (lots of string typed APIs). That does not mean that Turing-completeness prevents good tooling completely, it just requires more efforts and has some limits depending on a build tool`s software model.

Re: Why I Moved Back from Gradle to Maven

#42
post #30
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…

I'm not sure what's your point, but Maven allows to change source folder very easily. Maven has sensible defaults, that's right.

Re: Why I Moved Back from Gradle to Maven

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

- Gradle... It's an environment for programmer! I just write a bunch of code in Kotlin so that all 100 projects have a bit of my custom DSL that suits the needs of our application. The code takes the DSL and does all the job behind the scenes and most developers don't need to understand it. They can, but they don't need to. This is how it is supposed to work -- in a large project people specialize and the application should be created in a way that will allow people to not have to understand everything.

- Maven is strictly declarative. If you can't find a plugin you either dig up Ant or you have to write your own plugin. Not nice.

- In Gradle I can have almost everything declarative but I have the freedom to drop this bit of logic where it is really needed.

- Don't try to make it too complex just because you start using Gradle. Great power comes with great responsibility.

If I wanted to change one thing in Gradle it would be for the Gradle project to focus on debugging. I really find it difficult to figure out why things fail even though I have almost 20 years of experience with various languages and a decade of very intimate experience with Java. Make it easier so that people are not put off.

Re: Why I Moved Back from Gradle to Maven

#44
The whole article could be written about moving to maven. I still have no idea about how to do even trivial modifications to maven builds without googling them.

Fwiw, the need to learn groovy is a bit of a red herring because it doesn't help that much: I know groovy very well but I still find gradle confusing and have to google everything. My favourite build system of all time was gant, also based on groovy but a simple wrapper for ant. It had zero magic, was just a systematic wrapping of the ant API which itself was just a bunch of well documented useful build utilities. I found it very easy to use. The contrast between two build systems both based on the same dynamic language was very stark to me.

Re: Why I Moved Back from Gradle to Maven

#45
post #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.

> 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 to just drop into code).

Re: Why I Moved Back from Gradle to Maven

#46
post #5

> "Great Flexibility. Highly customizable build. You can easily create your own task and do whatever you want." Usually this is a red flag for me. People's apps really aren't that different, if you're doing some weird customization its going to be a nightmare for the next guy to maintain.

If someone wants customization, he'll do it. If build tool will be on his way, he'll write PowerShell script, generating Perl script using M4 and you'll live in a some special level of a nightmare. Gradle has a lot of plugins, so typical builds are possible just like Maven (there might be exceptions, of course), but if you need to customize something, I think that being able to write an ad-hoc task with Gradle is better than not being able to do so.

Re: Why I Moved Back from Gradle to Maven

#47
post #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 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, wifi, cloud), apps to manage stuff in my Drive. My changes are mostly adding dependencies.

Re: Why I Moved Back from Gradle to Maven

#48
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 is a counter-argument. When I need to understand project configuration I expect structure, not behaviour.

> If you can't find a plugin you either dig up Ant

Been doing Java software engineering for many different projects in various industries on all scales and I only had that problem once or twice.

Re: Why I Moved Back from Gradle to Maven

#49
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?)

Groovy is actually an extremely useful language to know. Something approximating bash for java, but with capability to scale up to full application development. Gradle would be one of the less important reasons to learn it imho.

Re: Why I Moved Back from Gradle to Maven

#50
The advantages/drawbacks section could easily apply to Java as a language itself as much as to Gradle. Flexibility and performance traded for unending complexity, all-encompassing scope (creep), and the subsequent unpredictable behaviour/side-effects which the latter creates.

Which makes this backlash entirely unsurprising because the mainstream foundational tools will eventually end up reflecting the culture of the programming language, given enough development time and an unconstrained mandate seeking to keep the wider community happy.

Post reply on HN