Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Move from Gradle to Maven

blog.astradot.com

Post reply on HN
Print view View original

11–20 of 44 posts

Re: Why Move from Gradle to Maven

#11

Post by voodootrucker »

For practical reasons, I have to admit gradle is better than maven. Gradle is least bad.

However, I do have to say turing completeness in a build system is an anti-goal for me. You shouldn't have to guess if your build will halt. I've seen terrible things done in builds, and most importantly, static analysis is the point of these systems... it's what makes IDEs able to work.

From what I understand the turing complete code in gradle merely builds the model, which the IDE (or gradle) can then use to run the build, but still...

Finally, if you do have to use a turing complete language, it sure would be nice to use one with static types. I know groovy syntax reasonably well, but without auto-complete on my build scripts (less my project), except at run time it's crazy hard to know what to type. And god forbid you have to debug it. I've added for loops to print out every variable, and for god sakes I've even had to attach a debugger to my build to figure out what it's doing. That's just nuts.

[edit] And finally, let's not ignore that fact that groovy tries very hard with it's closure syntax to look like JSON, so many developers paste in code from stack overflow and think it's actually configuration. (I actually kind of like that for other uses of groovy).

[edit2] apparently they know it's so bad gradle (the "gr" comes from "groovy") now uses kotlin for it's own build scripts (like on their github repo). If anyone's done gradle with kotlin I'd love to know if it actually helps.

Re: Why Move from Gradle to Maven

#12

Post by usrusr »

michaelcampbell wrote: post #9
rektide wrote: post #5

super short post, on a topic that seems not super relevant to many. but i dig it. i dig it a lot. languages are a pain in the butt. you can do anything with languages. so can everyone else using the language. it's actually quite nice having constraints. having a uniform model, having dead inert data. everyone using the same machine, the same mechanisms. maven's lifecycle[1], the steps of a build, being well defined,…

Yeah, I'm a big fan of Groovy (and Kotlin, though I know it less), but what bugs me about Gradle is, at least when I last used it which to be fair is some years, is that it solves 50% out of the box. Maven was closer to 85%. The Gradle manual started with, "here's how you write your own tasks!" I don't want to write my own; I want to know how if I need to, but you're saying I need to right off the bat. Maybe that was…

You make it sound as if writing a task was like writing a plugin. That might sound very close to the truth if you look at it through maven goggles, but if you take a step back to the structured shell scripting of makefiles it's hardly surprising they start with that.

For me, my main gripes with gradle are that freshness determination is quite difficult to analyze (and quite easy to break when you start doing nontrivial things, and if it breaks it is far too easy to just live with the additional build duration), that learning curves can progress way too far without real understanding of the central principle of configuration time vs task execution time (stronger syntactic separation might help, teaching "build your own task" early surely is an attempt to help as well) and, most of all, that all those "superconvenient" DSL syntax shortcuts are almost but not quite universal. "You can use DSL simplification xy everywhere, except where you can't" and there are far too many different xy. Maybe I should give the .kt syntax another chance, last time I tried I was in a phase of the learning curve where having a different syntax than in all the Google results was definitely a showstopper (trivial things are surely well-documented for kt, but when you reach xkcd 979 corner cases you'd better be firm enough in the groovy syntax to do the language transfer in your head without any uncertainties)

Re: Why Move from Gradle to Maven

#14

Post by manyxcxi »

voodootrucker wrote: post #11

For practical reasons, I have to admit gradle is better than maven. Gradle is least bad. However, I do have to say turing completeness in a build system is an anti-goal for me. You shouldn't have to guess if your build will halt. I've seen terrible things done in builds, and most importantly, static analysis is the point of these systems... it's what makes IDEs able to work. From what I understand the turing complete…

Yes. The Kotlin DSL helps immensely- probably mostly because the IDE can actually autocomplete the various closures and attributes.

A few things get a bit more verbose/ugly but mostly it’s similar.

Re: Why Move from Gradle to Maven

#15

Post by voodootrucker »

manyxcxi wrote: post #14
voodootrucker wrote: post #11

For practical reasons, I have to admit gradle is better than maven. Gradle is least bad. However, I do have to say turing completeness in a build system is an anti-goal for me. You shouldn't have to guess if your build will halt. I've seen terrible things done in builds, and most importantly, static analysis is the point of these systems... it's what makes IDEs able to work. From what I understand the turing complete…

Yes. The Kotlin DSL helps immensely- probably mostly because the IDE can actually autocomplete the various closures and attributes. A few things get a bit more verbose/ugly but mostly it’s similar.

Thanks! If the build model is statically analyzable I can see how that would help a lot.

I'll generate my next project with gradle/kotlin and report back :)

Re: Why Move from Gradle to Maven

#16

Post by johnisgood »

nanagojo wrote: post #2

Strange, gradle is just way faster in my use cases. Maven has always been a pain with regards to speed with handling dependencies.

If Gradle is fast in comparison to Maven, then I cannot begin to imagine how slow Maven is. A build system that has to spawn a daemon to speed up the process is a pretty shitty one. It takes about 2-3 minutes to do that for me, and still it takes 30 seconds to build my program which is not even that huge.

Re: Why Move from Gradle to Maven

#17

Post by elygre »

johnisgood wrote: post #16
nanagojo wrote: post #2

Strange, gradle is just way faster in my use cases. Maven has always been a pain with regards to speed with handling dependencies.

If Gradle is fast in comparison to Maven, then I cannot begin to imagine how slow Maven is. A build system that has to spawn a daemon to speed up the process is a pretty shitty one. It takes about 2-3 minutes to do that for me, and still it takes 30 seconds to build my program which is not even that huge.

Are you saying that it takes 2-3 minutes to start the grade daemon? That sounds weird.

Re: Why Move from Gradle to Maven

#18

Post by winrid »

johnisgood wrote: post #16
nanagojo wrote: post #2

Strange, gradle is just way faster in my use cases. Maven has always been a pain with regards to speed with handling dependencies.

If Gradle is fast in comparison to Maven, then I cannot begin to imagine how slow Maven is. A build system that has to spawn a daemon to speed up the process is a pretty shitty one. It takes about 2-3 minutes to do that for me, and still it takes 30 seconds to build my program which is not even that huge.

Something is wrong with your setup methinks. Gradle daemon starts in a second or so for me on the two Java projects on this machine (around 20koc each) and like one second build times...

Re: Why Move from Gradle to Maven

#19

Post by imtringued »

cutchin wrote: post #10
cutchin wrote: post #8

This is an oddly unconvincing little write-up. Firstly, learning gradle doesn't mean you are learning Maven simply because most dependencies use pom files for their metadata. I just means there's a little XML document embedded in your dependencies that 99% of developers never pay attention to, whether they're using Maven or ant or any other build tool. It's entirely irrelevant. Secondly, Gradle does not require you t…

Since I mentioned Gradle aggravations, I'll share a couple: 1. Bizarre and inscrutable syntax. They say things like "build scripts are just Groovy code", but some things, like how you define sourcesets or configurations, don't look like anything that should parse, much less compile, in any C-like language. They're doing some fancy meta-programming stuff behind the scenes to keep things light and simple, but it really…

It's regular Groovy. Look at this unrelated library that is doing the same thing. Toggle from Groovy to see what it is doing behind the scenes. https://spreadsheet.dsl.builders/#_outlines

The first parameter in a Groovy closure it will be treated as "this" and any function you call can applied to "this" first.

sourceSets is just a function that accepts a closure whose first parameter is sourceSets (this is implementation specific). If you call main inside the closure then groovy will call sourceSets.main and set that property.

What you are probably complaining about is that parenthesis are optional in two contexts. Your function fits on a single line or your last parameter is a closure (curly braces)

You're also confused by the fact that you can pass a map as a parameter by simply doing "function key1: name1, key2: name2".

Post reply on HN