Hacker News Reader

Comment by cutchin | Hacker News Reader

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 to learn Groovy. Use Kotlin if that's your thing - I get the impression that's the preferred DSL nowadays anyways.

Sadly I think those are the only two reasons really presented. Neither is especially convincing. IDE support seems just fine for both platforms.

I actually _like_ Gradle and I think I could come up with a longer list of things about it that aggravate me. But either way, use whatever build system you want, and if, as stated, their projects have fairly humble requirements build-wise, I'm sure either system will get the job done.

View on HN

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 isolates (and possibly alienates) developers from exactly what's happening under the covers. The Kotlin DSL seems to help make it more clear what's going on, but I haven't used it much yet.

Having used Gradle for years, it is strangely off-putting how unsure I often am about whether to put a colon in a particular place or a comma, or if something should be in parenthesis.

2. If you want to do anything beyond what's documented you can get into a bit of trouble, and if you find answers more than a couple of years old there's a good chance they often won't work. Making sense of the DSL documentation is sometimes a little tricky.

Beyond that, I would dare say it's the least awful option for building for the JVM. Their documentation is very comprehensive, it's fast, they are very fair about providing deprecation warnings before features are removed. It's rare I find a case where I'd like to use some external library that has a Maven plugin but no Gradle support.

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".

I have used both and like maven better. I do not like the idea of using a turing complete language to define your builds. Every Gradle project I worked on eventually devolved into build code insanity.

Give me any maven project and I can figure out how to build it and modify dependencies and stuff within minutes.

With Gradle, it can be an hour of messing with code if the project maintainers got creative.

I've never had a project that maven, with it's mostly fixed build setup, couldn't handle. Having a turing complete build script is like turing complete cooking recipes. Pointless and definitely going to create more problems than it solves

Reply on news.ycombinator.com