This message was deleted.

But man, no, please no yaml!

So Gradle are replacing Groovy with Kotlin, while Jetbrains are replacing Kotlin with YAML? Hello left hand, have you met my good friend right hand?

IMO YAML is a good compromise between being human- and machine readable. It's much better than JSON for sure for the sake of declarative configuration.

relevant whitespaces are evil 😄

It educates you to work cleanly 😉

ahem...

when the software stops being about “you” and starts being about “us” cleanliness needs to be imposed as a natural result of the system otherwise we all end up wading in each others effluent. See Javascript vs Typescript for example.

@melix We'll share something related that we are working on soon. Stay tuned 😉

ahhhh, now you get my attention 😄

relevant whitespaces are evil

YAML has much more serious issues, such as a completely batty type system/nonsensical type coercions, no effective standardization, a track record of security vulnerabilities, lack of truncation detection and so on

I think we got it. But please don't let this Amper announcement diverge into a YAML bashing.

I remember seeing a prototype of an alternative INI-based non-Turing-complete buildscript language for Gradle, but I can't find references to it anywhere

Is the Amper demo closed source?

I feel this is missing the point. In it’s pure form, well written, strict syntax, Gradle build script is identical in both Groovy and Kotlin (well done on the team) and it’s very near to a YAML or any other format you may think of (aka parsable). Creating another way to express the build configuration is not the way to go. Instead, a focus on making a “strict” Gradle DSL which would end up to something similar to Starlark (build for efficiency and parsing). That doesn’t mean we have to invent or introduce another DSL language but maybe just a subset of the combined DSLs is enough. What kills parsing and efficiency is the ability to just declare anything your heart desired into a build script. However, such ability is also a very strong feature of Gradle (when used correctly).

regarding YAML: indeed one of the worst aspects for build systems is the version declaration. It is definitely not well suited for this use case. For example, if you happen to declare

version: 1.10

, you will have some surprises. However, I do agree that having something which is more friendly to IDEs and analysis tools is required. This is a strong obstacle to Gradle adoption today. If I were to rewrite Gradle from scratch, I would probably change things so that the so called "build scripts" are actually a limited DSL like Daniel said, which is easier achieved by using something like yaml (meh!) or TOML, or Dhall. Then everything like task implementation, task registration, etc would have to go into plugins. However everytime I thought about where one should stop, it is not that clear. So I'm curious what the Gradle team is working on. If it addresses the 80% use case, we're in good land.

I've seen both kinds of build systems: ones where the configuration language is limited to start with, and eventually needs escape hatches, and ones where it Turing-complete, and eventually needs to be reigned in for various reasons. Gradle has gotten impressively far with the second

Definitely a subset of the current DSL is more desirable then a completely different format, IMO. I got some pretty good success with build script composition and switching between Kotlin/Groovy in testing scenario by purposefully limiting the supported keywords and approximating some of the parsing and it work fairly well. If Gradle wants to solve this, it’s definitely doable without pulling the rug under everyone that love the power of the Kotlin/Groovy DSL (when needed).

the issue with scripts is that it's extremely hard for tooling to inspect. Most tools only do things like parsing. Using the TAPI is not always possible (e.g for security reasons).

I agree, having a strict format that help tooling to inspect would be great. If a user decide to use things outside the strict format then it’s acceptable for the inspection to fail. I agree that TAPI is a big security liability but I also love the fact that I can prototype anything in a single file or patch things without having to write a plugin. I’m also very curious on what the Gradle team have planned.

Probably an AI driven build system with declarative rules:

Use Micronaut 4.1.1
Add support for building with GraalVM
Add functional tests so that I can check the behavior of my application on Java 17 and Java 21
Make sure that I cannot release if there's a binary breaking change

@melix, I don’t think the AI-conversation interface addresses the same concerns, but I genuinely think that such a thing should exist. It can work the same way things like Copilot work today: you talk to it in your language, and it proposes changes to the underlying build files. It would definitely help if the build files were declarative, and maybe even strictly so.

Yeah that was a pun. I am actually scared about what an AI system could generate for Gradle, especially if trained on Stack Overflow 😄

imagine a world in which each Gradle release is actually a multi-GB LLM… or maybe don't imagine that

Here's what we are working on https://blog.gradle.org/declarative-gradle. Let us know what you think.

Thanks @Piotr Jagielski, so that's basically what @daniel described. I'm personally not sure I'd go that route, but it's good to see efforts to limit what users can do in a script. I think the issue you're going to face quickly is that folks who see a limit will move things to buildSrc where these do not apply, effectively working around. That's why I think a dedicated language for what you call build definitions makes sense (but no YAML, definitely not suited for builds IMHO).

Yes, it looks we think very similarly to Daniel on this 🙂 As to your point, that's why we think "Match the software definition to the software domain" is also important so that there should be no reason to move things to buildScript for most users.

Can you clarify how this relates to Amper? The post says

At the same time, JetBrains is running an experiment with similar goals called Amper. One of our objectives is to leverage this experiment to benefit the development of Declarative Gradle and provide a great user experience for Kotlin and Kotlin Multiplatform. Therefore, in addition to the dedicated group focused on Declarative Gradle, we are working closely with the Amper team at JetBrains.

which suggests that the two initiatives are largely parallel, but will influence each other? Is the goal to converge at one solution at some point?

Yes, Amper is a separate experiment run by JetBrains. We are in touch with them, and they are sharing their learnings with us. At Gradle, our goal is to provide the best possible experience across all supported ecosystems. I hope it will all converge on Gradle-native solution 🙂

Feels like a competition 😄 It's definitely interesting to see two initiatives with very similar goals announced pretty much back to back

Amper is not a build system, so it's not really a competition. Technically it's a Gradle plugin and it's also highly experimental at this stage. It was announced back to back because we coordinated the announcements with JetBrains.

For sure the method of implementation is different, but Declarative Gradle is

restricted DSL that separates the software definition and build logic so that the build language is fully declarative

and Amper

provides a configuration layer on top of Gradle and is implemented as a Gradle plugin.

So from an end user perspective, both work to the effect of being a simpler, declarative layer on top of Gradle. And it doesn't seem like it makes sense to use both at the same time, that's why I mentioned it looks like competition 🙂

any rough ETA for the declarative Gradle?

Is the Amper demo closed source?

@Ryan Schmitt Yes, for now. We plan to make sources available soon.

The plan is to have a prototype this year and an initial solution for early adopters early next year, starting with Android

any rough ETA for the declarative Gradle?

this seems like caving to the maven people, no? i have had to switch to maven this year and its awful. i mean (to borrow my managers words) "it works really well in a regulated environment where you are not expected to do much anyways" - is this the end? i mean, it was a good run...

I don't see it that way. It will be very different than Maven. Part of our vision is an elegant and extensible declarative build language that allows developers to describe any kind of software in a clear and understandable way. I don't think you can say that about Maven. We haven't fully realized that vision for Gradle but this project is a key step in this direction. With declarative, Gradle will remain as flexible as it is (much more so than Maven), and build engineers will still be able to use that flexibility. So in short, it will be much simpler for developers and as flexible for build engineers, so the best of two words.

I love this direction. I am underwhelmed by Amper, but the idea of a restricted kotlin DSL that is declarative only is much more appealing

Yes, I'd rather keep everything in Gradle than have leaky abstractions stacked on top of each other; incrementally adding wrappers, generators, and templates one at a time is how you end up with autotools

Starlark (as mentioned upthread) is a interesting comparison. ~Bazel~Blaze also evolved from a full embedded Python to a subset DSL. but that happened while it was still internal to Google, no need to worry about backwards compatibility for public consumers

Is this repo part of the research? https://github.com/buildfoundation/ketolang

Ketolang is a dialect of Kotlin without side-effects, it allows only immutable data and pure functions.

Ketolang aims to cover use-cases of Starlark language but in compile-time, type-safe environment of Kotlin, with benefit of running in a more performant environment than an interpreter (JVM, Native and maybe JS).

Yes, we know about ketolang

Correct me if i’m wrong, it’s been years, but wasn’t there an effort to create a declarative “Gradle Software Model” some years bear? I’ve lost context in the intervening years, but how is this related to that aborted effort (or is it not)?

The "Software Model" was about "how to declare software to build" for various ecosystems (JVM, native, etc). This is more about "how to write your build script". It's a bit confusing when projects like Amper think that creating more layers makes the lasagna taste better. 😄

@Ben Madore There's also Gradle Module Metadata https://docs.gradle.org/current/userguide/publishing_gradle_module_metadata.html

The Gradle Module Metadata is a format to represent published variant-aware components by Gradle and its dependency engine. So its more related to publication and dependency resolution.