No, not even. Gradle is working on a new declarative DSL. As for Amper, so far, there's been conflicting information on whether it's a layer on top of gradle or not. If it is, then I fear it will add too many new failure points to be worthwhile.
@oharaandrew314 Isn’t Amper both? The problem is that we want a JFDI build, where we can also customise everything when we have specialist requirements
I don't know if the Kotlin DLS is any "better" than the original Groovy DSL. They say you're supposed to take advantage of the autocomplete to inspect available properties, but as you've seen, the script doesn't even get syntax highlighting until it's fully correct, so I rarely actually get to use it. This doesn't make the Kotlin DLS any worse though; I think both are about the same amount of pain to work with. But for consistency, I might as well use the Kotlin DSL in my Kotlin project. And since I don't even know Groovy, at least I know what my copy-pasta is doing.
In my opinion is a lot better, the problem with groovy gradle files is that people at some point tend to write scripts that works by accident, they dont declare plugins but declare extensions for them and the plugin is applied in different file etc. This leads to IDE being completly useless, hovewer in kotlin due to type safety it forces you to write better code, and IDE is actually helpful.
Version Catalog should probably be your next hurdle, it really does make updating dependencies MUCH easier (and less error prone) one large multi-module project and I like that the catalog is reusable between projects, a little fiddley to get strings and such, but honestly makes everything so much nicer once done.
Welcome to the party! Perhaps just in time for the new declarative DSL to drop!
All the more content to thrill you with
You jest, but Jetbrains are working on a new build system...
No, not even. Gradle is working on a new declarative DSL.
As for Amper, so far, there's been conflicting information on whether it's a layer on top of gradle or not. If it is, then I fear it will add too many new failure points to be worthwhile.
@oharaandrew314 Isn’t Amper both? The problem is that we want a JFDI build, where we can also customise everything when we have specialist requirements
I don't know if the Kotlin DLS is any "better" than the original Groovy DSL. They say you're supposed to take advantage of the autocomplete to inspect available properties, but as you've seen, the script doesn't even get syntax highlighting until it's fully correct, so I rarely actually get to use it.
This doesn't make the Kotlin DLS any worse though; I think both are about the same amount of pain to work with. But for consistency, I might as well use the Kotlin DSL in my Kotlin project. And since I don't even know Groovy, at least I know what my copy-pasta is doing.
I think this sums up my view. Neither is good enough, Kotlin is a bit better.
In my opinion is a lot better, the problem with groovy gradle files is that people at some point tend to write scripts that works by accident, they dont declare plugins but declare extensions for them and the plugin is applied in different file etc. This leads to IDE being completly useless, hovewer in kotlin due to type safety it forces you to write better code, and IDE is actually helpful.
Version Catalog should probably be your next hurdle, it really does make updating dependencies MUCH easier (and less error prone) one large multi-module project and I like that the catalog is reusable between projects, a little fiddley to get strings and such, but honestly makes everything so much nicer once done.
At the risk of flogging a dead elephant, this is on my list for next week!
Why didn't you use the AI to help fix the issues?
To be honest, because when I tried that in a run-through (I prefer the term to rehearsal ;-) it just dug me in to a deeper hole.
Who cares about removing the apply? If it works I would leave it.
I suppose my thought was that if I had other builds to convert, the extension would save a bunch of manual work.