Feature: Author YAML/TOML Gradle Builds

[AbdhilahiRWabwire]

Expected Behavior

Author YAML/TOML Gradle Builds

Current Behavior (optional)

Increasing Extreme Complexity && Customizability

Context

I want to author my builds with YAML or TOML I understand that Gradle Builds are extremely customizable but the unnecessary increasing complexity of builds all over the Java and Kotlin software ecosystem is a direct consequence of the constantly increasing Grade Build features and customizations. It will eventually reach the point of complexity collapse. This is inevitable and will destroy the entirety of the Java and Kotlin software ecosystem. The best feature Gradle could possibly release is the ability to author Gradle Builds in YAML or TOML. C#, Dart, Go, and Swift also have build systems and package management systems that do not allow, require or use the level of customization that Gradle Builds allow. If you can't do this then please, at least stop adding customizations and features. Developers spend more time authoring Gradle Builds than writing code.

[oleg-nenashev]

Hi @AbdhilahiRWabwire . Thanks for raising this. Many points in the context are debatable, but I share the perception that Gradle complexity grows and impacts developer experience, especially for newcomer users. Indeed, there is a demand for something more simple.

In fact, there are two major efforts on this matter:

• Declarative Gradle by the Gradle team - simplified(?) version of Kotlin DSL
• Project Amper by JetBrains that currently focuses on the YAML syntax

We’d love to know how you feel about our vision and plans for developer-first software definition. As always, let us know if you have any questions or feedback on our forums or Community Slack.

[AbdhilahiRWabwire]

Amper YAML is definitely the way to go.

[oleg-nenashev]

Might be. I do have too much trauma from YAML based build tools from the CNCF space. "YAML as is" not very flexible beyond very basic use cases, so this effort will most likely end up with "Kotlin DSL inside YAML". It is viable provided there's a proper IDE support.

Personally I would prefer a pure Kotlin DSL, but in such a case, the challenge is the balance between complexity and flexibility for advanced use cases, which is also not trivial.

[AbdhilahiRWabwire]

Look at the Dart/Flutter YAML syntax. Dart YAML allows developers to structure their projects and author multiplatform builds in the most simple way imaginable. After you have witnessed Dart/Flutter YAML your life will change. When YAML is used properly, it is beautiful to look at. Look at Go language modules go.mod, it is gorgeous. Look at Rust Cargo TOML, it is glorious in it's presentation. Look at C# Dotnet XML, it is dusty but modern and savoury. Look at the Swift Package Manager API, it is incredible to witness. If these things are done right, they can be incredible. Use other build systems as inspiritation (Even if the differences of the target languages are significant, the developer experience can be similar).

The Groovy and Kotlin Scripting Domain Specific Languages are anti-developer and developer-last. Especially when compared to the syntax of the file types and command line interfaces used by the build systems for the languages listed above (Once again, despite the differences of the target languages). Gradle is a build tool and it's users are Software Engineers, not "Build Engineers". The entire concept of a "Build Engineer" breaks the Rule of Least Power in Software Engineering. Gradle could offer cloud builds on virtual machines to enterprise customers/individuals and provide a CLI with a Groovy interface to satisfy the "Build Engineers". Gradle should be charging these "Build Engineers" money for their uncontrollable urges to be satisfied in the cloud. There are entire companies listed on the CNCF landscape that do Continuous Integration, Continuous Deployment, and Orchestration, so why can't that satisfy the "Build Engineers"? Software Engineers need build tools. Gradle is that build tool in this instance.

Stability, reliability, reproducibility, and backwards compatibility seem non-existent. Multiple definitions exist for the same tasks. YAML is easier to migrate to than whatever DSL is in current or future use. Therefore switching to YAML would not increase the current level of complexity. Developers are apathetic to it because our builds are guaranteed to be deprecated no matter what because DSL API's are moving targets by default, they change over time. The amount of change over time is dependent on the implementer. The fact that we have become used to this, says a lot. Backwards compatibility doesn't seem to be a concern.

There has to be some kind of rules. A few laws. Land cannot exist between human beings without the laws of nature and justice. Our universe has it's own laws. Why can't Gradle lay down the mighty, tender and sweet gavel of justice on this lawless land?

[oleg-nenashev]

Hi. Sorry for the response delay, I was doing some internal follow-ups and preparing the infrastructure. To address the main concern, all points about build stability and migration are valid, and we should ensure stable specs and APIs regardless of the format. Indeed, Kotlin DSL might provide more temptation to deprecate things and move on, but it is not what should happen

For now, I moved the issue to the new integrations repo for any reasonable and important feature requests that are likely to be implemented in other repositories and external integrations. It still remains a source of feedback for Declarative Gradle

[AbdhilahiRWabwire]

Thank you good sir. I really appreciate it.