2 ms·
My experience with gradle (5+ years ago) was that there was too much "magic" going on. It would do things without me specifying that it should, like convention-
by justin_oaks 6y ago
My experience with gradle (5+ years ago) was that there was too much "magic" going on. It would do things without me specifying that it should, like convention-over-configuration taken to its limits.
Has that changed over the years? Has it gotten better or worse?
- jpgvm 6y agoBetter in some regards, worse in others. The Kotlin DSL I think made things a lot less magic at the cost of being a bit more leaky with abstractions.
- Rapzid 6y agoI believe for years they have been trying to improve the experience for use cases that aren't an opinionated, old school, Java publishing pipeline. Both through the API flexibility and documentation that explains more about the concepts of what's going on behind the scenes(how the Java plugin configures a bunch of tasks by default, what they are, and etc). The "new" publishing system is still a thorn in my side. It doesn't play well with existing Gradle paradigms(like configurations) and seems to force most people into giving up on it when they have some variation of the use case "Publish a dynamic list of files(aka unknown list) produced by task/subproject and not the stock Java tasks." There's a trail of frustration going back nearly a decade; unanswered questions, answers that don't address the use cases, and a general lack of acknowledgement that the "new" system isn't getting the job done for people in a friendly, flexible way.