> this was the idiomatic way to build "enterprise" software a few years ago, right? Inversion of control, automatic dependency injection, service discovery, configuration over code, builder patterns, ORMs, DSLs, and on and on.
All of that remains true for enterprise today as well.
And for the record, Gradle doesn't really check any of the marks you just listed, only DSL if you are squinting a little.
Gradle is basically a application to run generic groovy code. There are literally no limits to what you can do, as you've got a full JVM to play with.
Right, but running code to create configuration for other code, which is how I remember the build system working, is the same kind of inception-like abstraction that I was referring to.
As to that "no limits" thing: I see that as part of the problem and complexity of using Gradle. Everything is abstract and open. But at the point where you can do literally anything, maybe we'd be better off with a build library that we could just call from whatever language we're using? Why do we need another language to do "literally" anything?
I'd agree that a lot of the SMB/large enterprise software devleopment practices make trivial domain requirements into extremely complicated distributed monoliths colloquially called "microsrevices", but gradle is a pretty bad example for this kind of behaviour.
gradle was created as a kneejerk reaction to maven forcing build configuration to be set in stone and in xml. Its inspired by dynamic scripting languages, which is as far removed from these companies as you can get.
I remember it being created shortly after groovy became massively overhyped, and I think the only tools still using it are gradle and Jenkins...
To be fair (to myself :) I was just saying that Gradle was a product of its time. It might not have all the problems of "enterprise" software from that period, but I certainly felt like it was overly general; almost as if it was an experiment in inverting configuration and code. I did actually prefer Gradle over Maven but in truth I found both to be pretty impenetrable.
All of that remains true for enterprise today as well.
And for the record, Gradle doesn't really check any of the marks you just listed, only DSL if you are squinting a little.
Gradle is basically a application to run generic groovy code. There are literally no limits to what you can do, as you've got a full JVM to play with.