This message was deleted.

That sounds great. 7 years ago I wrote something to enforce more strict buildscripts by dissallowing if statements, loops, task creation and long configuration blocks based on the gradle lint plugin: https://github.com/breskeby/gradle-lint-rules/blob/master/src/test/kotlin/com/breskeby/gradle/lint/rules/NoIfRuleIntegrationTest.kt

This sounds like a great idea, and yet 0% of what I wish you were working on. I hope that it ends up being like

var

in java... where it was something I didn't realize I needed/wanted. I love the idea of declarative, but statically typed, but gradle has so many other problems that I'd rather see fixed than creating a new language. > However, it is difficult for IDE vendors to automatically change the software definition or create a UI editor when arbitrary code is possible in build scripts. ... what? that's literally an IDE's primary job, to allow me to write arbitrary code all day long. I'm really worried that what this does is force all editors to support yet another language. In fact given the collaboration this sounds like a good way to have vendor lock in. Are you going to confirm you will collaborate a plugin for vscode? or vim? it was only very recently that vscode got support for using gradle with kotlinscript correctly. Basically big thumbs down from me, this is not a current pain area, it used to be, but the kotlin dsl has gotten much better. Oh, and I definitely don't want yaml unless you can promise me that when the indentation is wrong, that you'll throw the line error at the correct line. Yaml has a couple of good ideas that are unfortunately not even supported by a lot of yaml vendors... but the worst thing is most yaml parsers throw poorly on line numbers. I will say I spend an unfortunate amount of time as a developer working on build engineering. Although 90% of that time isn't really about the "DSL/API", instead it's around gradle's defaults and other deficiencies. I literally just wrote 5 tickets around a wrapper shell script I had to write because gradle doesn't behave in a correct/easy manner. I'd much rather not have to explain the existence of such a thing to someone new to gradle, than have this. I think it would be time better spent trying to knock out the confirmed bugs on github. Why I think people think this is necessary. It's impossible now to tell if "this is the recommended API" eager configuration hasn't been deprecated, nor are the API's well documented. Some processes are currently cludge, but that could be fixed by improving the current DSL and defaults, not making a new "language". A note on build engineers, I've worked for big and small companies, I've yet to meet one. It's always a developer on the team. That's my feedback, sorry it's not super positive. Hopefully something constructive can be derived from it though.

Hi Caleb. Thanks for the feedback! There is actually quite a lot to address. As a Gradle user I can totally relate to some feedback, and happy to chat! Do you prefer responses in Text, or a virtual coffee?

? virtual coffee? wdym? happy to chat

Probably video chat, like meeting for a coffee, just virtually. ;-)

either/or if that's the case. Might depend on your accent due to my various hearing issues. I find high bandwidth (video/voice) often works better, unless the hearing issues become a problem.

We could try. I have a Russian/Slavic accent, but it is relatively mild