[rektide]

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, in order, serving as a backbone for plugins to extend, is powerful in it's ordered simplicity, in it's learnability, in it's familiarity.

i have barely touched jvm in the last decade, but even a decade ago, i think the lessons here are really killer, really key, really insightful. it's not apparent exactly how this applies to a broader scope of computing, but i think there are some really important lessons we still need to grapple with. that languages offer too much freedom. that being able to do anything ends up with everyone doing something different, a proliferation of hell as other people's code, other people's endless variegated opinions, all unlike, all foreign.

that said, maven leaves extreme power in the hands of it's plugins. plugins do a lot. i spent years combing through docs, & looking at different project builds, & maven retained a vast aura of mystery, left endless questions abound. i resisted going further, understanding what plugins really were, looking at what they were doing. once i started reading their sources, i was quite surprised to find many of the plugins i thought powerful & special were actually quite short, often rather simple manipulators of a couple of files. it took diving in to see how elegant & simple maven & it's vast sea of plugins really (often) were.

[1] https://maven.apache.org/guides/introduction/introduction-to...

[michaelcampbell]

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 an issue with the manual vs. the tool, but if the build tool needs documentation to tell me how to build a build tool on chapter one...

[antonyh]

To make it worse, every Gradle project I've come across has different solutions for the same common tasks. With Maven it's more-or-less standardised, because custom plugins are rare (I've come across just one in 20 years, and I wrote it for a special purpose). Embedded Ant was more common, but thankfully rare now. Everyone just uses the same handful of plugins in my experience.

Agree that Groovy is awesome.... as a compliment to Java. I'd learn to dislike it quickly though if I had to write an entire project with it.

[usrusr]

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)

[michaelcampbell]

> You make it sound as if writing a task was like writing a plugin.

In that you have to write something, it is. Which is my point. I had a very vanilla product; I couldn't do it with vanilla Gradle. I also couldn't find in the documentation how to do "normal stuff"; or at least it wasn't early. It started RIGHT OFF with "here's how you customize it!"

No, start with the 80%, deep dive into deeper stuff, later.