:loudspeaker: Help us transform build setups! We’...

# announcements

[Maria Krishtal]

📢 Help us transform build setups!

We’re on a mission to simplify build configurations and we need your input. Whether you’ve wrestled with YAML, the Kotlin DSL, or something else, we’d love to hear your take on a potential new approach. Check out our survey!

👉 https://kotl.in/67loo2

[mbonnin]

I didn't even know maven(dependencyNotation) was a thing. Or is it?

dependencies {
  maven("g:a:v", exported = true)
}

Or is it made on purpose as a potential replacement of implementation /`api`?
It's hard to have an opinion on the proposed syntax without more context how to interpret it.

[altavir]

This is not plain gradle. This is some kind of hypothetical "improved" thing.

[mbonnin]

👍 I answered in that way but found it hard to separate the "pure syntax part" from the "semantic/gradle part". Maybe I like the syntax but the semantics of it are confusing or the other way around.

[altavir]

The same. I think I like the new kotlin-like syntax. But I don't like things that are clearly not-kotlin-like. For example something{ "A", "B"}. I think that the same thing could be done in Kotlin without creating a new language. Because in the end, it will define how easy it is to customized the thing.

[CLOVIS]

Personally, I think the best outcome would be creating a lightweight Kotlin subset that has only the DSL syntax but nothing else. This way, we get maximal familiarity and readability, and minimal documentation/learning required.

[CLOVIS]

Ah, that's what the exported was supposed to mean? 🤦‍♂️

I answered in like half the examples that api /`implementation` was missing and that was very confusing, I never realized it was supposed to be that.

[vladimirsitnikov]

If "exported" is a boolean for "api vs implementation", then how do they suggest modelling compileOnly/compileOnlyApi? Exported=true/false/compileOnly/compileOnlyApi? :)

[CLOVIS]

Some examples had an additional scope = runtimeOnly argument, which I understand as the remplacement for everything other than api/implementation.

[CLOVIS]

I don't think I'm opposed to exported to mean api , it is indeed something many people are confused about, but maybe the form should have included some information on that.

It really does show that most of us understand snippets almost exclusively through naming familiarity, though.

[aurelien]

I have completed the survey, and I must say it is totally biased towards readability...

[aurelien]

TBH I don't really care if I need to spend 10 extra seconds or so to understand the configuration. What I feel is important is having good tooling, completion, grammar checks, not having to learn new specific key words, and my ability to build upon and extend the provided solution.

[aurelien]

I don't know if any of you stares at your KMP configuration before going to bed, thinking to himself "what a beauty", but I don't.

[aurelien]

Kotlin developpers already know and love Kotlin (it seems stupid to write it down...) So:
• stick to kotlin for building kotlin
• avoid the "yet another tool/DSL/language" when possible
• build good tooling in the Jetbrains ecosystem around it.

[altavir]

I am confident that it is possible to create an extension of gradle, which is both concise and does not involve a new language. For example kscience plugin provides a simplified modes and dependency configuration: https://github.com/SciProgCentre/kmath/blob/dev/kmath-commons/build.gradle.kts. And it could be made even better. Right now it somehow limited by kotlin plugin architecture.

[Gleb]

I am rather inexperienced when it comes to gradle. so I have no suggestions. Coding comes pretty easy for me and after a weel of experimenting with KMP I've had a decent grasp of the main concepts and approaches to certain problems even with the lack of documentation and a rather small stackoverflow catalog. But now even after a month of working with KMP and constantly messing around with the build files, I barely understand what's going on there and absolutely cannot do more than follow a step by step instruction. So for me and other people like me something like a gradle 101 (also 102 etc) on hyperskill.org could be highly useful. I know there are many other courses, but the hyperskill format imo works best as a crash course for fairly experienced developers and most existing courses lack practice and/or are presented in the format of immensly long texts that bombard you with everything right from the start or videos that take forever to get through and hard to digest

[Darryl Miles]

One area that could be covered better is every Gradle plugin produced should have a high-level overview of the tasks, order, structure, covering the interface into Gradle ethos, but then also the internal information towards the reason it exists and Kotlin support.
Each task should have a documentation section off the main gradle workflow order, to explain its purpose, the inputs and outputs and what things happen here, what things can be configured here, what things you can't/shouldn't do here (if there could be common misunderstandings).
Instead the documentation focuses on, this is what a configuration directive looks like, this is what the arguments are, this is the GUI button to press to run it, there is quite a bit that is assumed knowledge missing across a broad range of plugins.

Re work on DSLs in general.

I think work could be done more generically (not just for Gradle, but also custom DSLs) between Kotlin <> DSL <> Scripting, to extend the Kotlin DSL support to lean more towards being able to provide some more of the syntactic sugar of Groovy (in the KotlinDSL/Scripting space) and the 'implicit' type conversion concept of Scala made available in the KotlinDSL/Scripting space.

Maybe it is just missing a few additional annotations @DslImplicitTypeConversionAllowed to assist the compiler generating code where an object can be offered to a DSL API method to set a property, but the type doesn't have to match the property type (due to implicit conversion support being available in this area). At bit like having Property setter support being overload the accepted multiple types that can be the source of the data, while the backing field manages itself. This seems to be the main feature missing with the backend of the DSL. Because it allows helper methods to exist and then become hidden in the DSL syntax due to implicit type conversion the DSL user doesn't need to know, which specific helper method is needed to use in this specific context.

For the front end of the DSL (the parser) adding Groovy syntactic sugar, would be probably a trade off the individual DSL can decide to make. the syntax "something" { "item1", "item2" } if we can hide the helper methods that can perform the necessary type conversions in the DSL backend (this is how implicit maybe used also)
As in it might make the DSL syntax opinionated at the expense of not supporting a particular Kotlin feature. There are a lot of these where that would be preferred to make the DSL more straight forward at the expense of Kotlin features available to be written directly into the DSL (like bring back the Groovy syntactic sugar items)

With JSON and Jackson library there a @JsonAnySetter something similar would also be useful in DSL space that allow a method be marked to accept anything, allowing the object to be presented and allowing the DSL backend to decide if it can handle it and how. It is kind of an alternative and opposite to implicit conversion, in that it lets the data receiver deal with type conversion (but doing this reduces the quality of IDE DSL syntax support), but implicit conversion is better in that the data sender deals with type conversion (but you maintain high levels of IDE DSL syntax support at the same time); and it allow client extensions to the DSL to provide implicit that also just work and maintain highlevel of IDE DSL syntax content assist support.

[gildor]

It's a very good initiative, but I believe that the research is very flawed.

For complete newbies, difference between implementation/api, maven(exported = ?) and string interpolation is completely not clear, all are magical, also without knowledge of the context they cannot really recommend what would be better, build config is always require some knowledge or copy-paste

As an experienced developer, I have no context of research, and I have to guess a lot of areas, but I think many part of the research looks as just attempt to check "how should we rename gradle api/implementation", which I feel as pretty pointless bikeshedding discussion. It's not even in top 20 problems of Kotlin build configuration

We should probably first understand what Amper/Kotlin Plugin teams tries to do to help with it.

Because, if it will be a way of opinionated Gradle plugin, I do agree, we don't need special tool, we just need, well, opinionated greadle plugin as @altavir pointed out, it already doable with gradle, and vast majority of current complexity come from Kotlin plugin DSL, not from Gradle


If we solve problem of IDE model (auto-editing, sync with ide) then it almost inevitable to have some config language (it also can be somethign with Kotlin syntax, doesn't matter, just not YAML), in this case it looks contr-productive try to make it look as Gradle DSL, it just creates more confusion. but in this case, selection of this config format must be the most important task, not just "we will think about it later" as it now in Amper, because success of this feature will depend on the right choice of config laguage (and yes, YAML is wrong choice)

[CLOVIS]

This is mainly my problem with the Amper project, it's really not clear what it's trying to be.

What we do know is that the main problems they are working on are:
• the fact that the IDE cannot edit Gradle configuration files
• overall dev experience with editing build files
If the goal is to continue using Gradle as a backend long-term, then Amper should not be a separate project from Declarative Gradle. The death of Kotlin tooling is when the build tool and IDE authors don't work together. From an external point of view, it really looks like JetBrains and Gradle were initially working together, but had a fallthrough and JetBrains left to do their own thing on their own (mainly based on the tone of the Declarative Gradle announcement, which was just days after the Amper announcement, which says "ahah don't worry we're working on this with JB" even though the Amper announcement mentioned none of it, and the Gradle team has nothing to show yet. It really looks like they're trying to save face after JB left them). If this is true, then, at best, Amper will be something newbies create a project with, then get more and more frustrated as nothing can be done with it, because the ecosystem will still be based entirely on Gradle, possibly with Declarative Gradle as the main build tool.

Now, my personal guess is the Amper team is pushing internally to rebuild an entire build tool from scratch, but the JetBrains execs have not allowed them to say that publicly yet. That would explain them going in another direction than Gradle's efforts. I'll just be clear: if that's the goal, then the look of configuration files is the least of my concerns. Show us what it will be able to do.

Please, do not let this end with a fractured build tooling ecosystem in which we have different tools that all have less features than what we have today. It sure looks like that's the direction we're headed.

[Robin T]

Gradle is massive; It is actually not a build system but rather a framework for building build systems.

One thing I always do in my projects, is to change the source-sets to something like this

kotlin.sourceSets["main"].kotlin.srcDirs("main")
kotlin.sourceSets["test"].kotlin.srcDirs("test")
sourceSets["main"].resources.srcDirs("main")
sourceSets["test"].resources.srcDirs("test")

I also avoids deep packaging structures to achive simpler project strucutres like this:

project
└── build.gradle.kts
    ├── src                       
    │   ├── Main.kt
    │   └── logback.xml
    └── test                      
        ├── Main.kt
        └── logback-test.xml

This feels way less java-like and it gives smaller and easier-to-read project setups (opinionated).

The namespace-hell only makes sense when creating libraries that compete with popular libraries. Maven is polluted with transitive dependencies, this is really annoying and often only a veeeeery small fraction of the code in the transitive dependencies are used. Here Kotlin could make it harder to use java-libraries, and encourage the kotlin-community to replace it with something new.

[CLOVIS]

Here Kotlin could make it harder to use java-libraries, and encourage the kotlin-community to replace it with something new.

Considering Kotlin got there mostly by being so friendly with the Java community to the point where they decided to jump ship, I don't believe this would be the right way forward.

[Darryl Miles]

I agree on 'making it harder to use java-libraries' is a bad idea (if that was a point being made). But no problem on Kotlin reinventing things that are "better" along whatever metric or axis you chose to use on the day, it is part of the open source way. If any proposed solution is truly better there is enough variety, options and freedom let allow the good stuff to rise. So please do encourage a better replacement, I'll research it when it arrives.

[CLOVIS]

If any proposed solution is truly better there is enough variety, options and freedom let allow the good stuff to rise.

This is only true when software follows KISS and interoperability concerns.

Say a new JVM debugger appeared tomorrow that was amazingly better than what we have today. Most of us probably still would use the one in IntelliJ, because, well, it's the one in IntelliJ.

What I mean is, a build tool that doesn't have deep IntelliJ support may as well not exist.

[Marcin Wisniowski]

> I don't think I'm opposed to exported to mean api
I think people are reading too much into this. The survey was about the abstract syntax, the identifiers (exported/maven) are just example names that have no meaning other than to show syntax differences.
At least that was my understanding of the survey.

[Darryl Miles]

That was my understanding too, about your first impression of the syntax and form, hence my comments about items that lean back towards Groovy syntax (which I think supporting it a good thing when possible in a general purpose Kotlin DSL, not just Gradle/KotlinDSL). The questions/commentary did NOT ask you to focus on the meaning of the statements/directive, just more on your "feeling" towards what you see if you had to work with it. For me keeping just as much flexibility with less punctuation is generally a good thing to see. Which I think is already a Kotlin core principal.

[gildor]

The survey was about the abstract syntax, the identifiers (exported/maven) are just example names that have no meaning other than to show syntax differences.

In this case survey should clearly state it, and I still don't see any reason for discussing it without all other, much more valuable details, this is absolutely miniscule detail comparing to rest of topic. Also I don't really like calling it maven either, but it was not discussed

At least that was my understanding of the survey

We all guessing, and it makes it more confusing

just more on your "feeling" towards what you see

But it's impossible without understanding of context, everyone start inventing context and looks that many don't like it, this why I called the research "flawed"

[marlonlom]

@Maria Krishtal Done 👍 🙂

[edrd]

Hey, I know many people have an aversion to YAML (including me), but recently I found a project that fixes many of its issues:

https://hitchdev.com/strictyaml/features-removed/

This may be a good alternative, although it would require a Kotlin port, since it’s is written in Python.

[gildor]

Interesting, makes it a bit less of foot gun, but still ugly and I still have a lot of questions for lack of scheme language (so it has to be declared in python structure, also very basic) and many other features

From what I was recently very excited, is actually Pkl from Apple, also written with Java, which makes it a lot better in terms of integration and they even work on Kotlin Serialization support
I think it has a lot of important features, such as schema support, existing plugin for Intellij IDE and a lot more

But I still feel that maybe, Amper/Declarative Gradle should be more radical and actually follow Starlark instead, so create Kotlin dialect which is what Starlark for Pythn, so have simplified Kotlin syntax with limitations for APIs and syntax. It's a much bigger investment, but it one of things which fits better between config language and full programming language

[edrd]

Didn’t know of Pkl. Very interesting, indeed.

> But I still feel that maybe, Amper/Declarative Gradle should be more radical and actually follow Starlark instead, so create Kotlin dialect which is what Starlark for Pythn, so have simplified Kotlin syntax with limitations for APIs. It’s a much bigger investment, but it one of things which fits better between config language and full programming language
Makes sense too. I wonder if the investment would be much bigger, though. Theoretically, it could be implemented as a compiler plugin that restricts symbol usage. And now that K2 is on the corner, the IDE integration would be automatic.

[gildor]

So, Declarative Gradle went by the path of custom config language, syntactically compatible with Kotlin, essentially what I hoped for in my previous message, but as I see for now very limited (not on level of Starlakr), it's just a static DSL as I understand, which I suppose is a good starting point, it will cover vast majority of cases, static validation API would be great, but it probably could be done later

https://github.com/gradle/declarative-gradle/blob/main/unified-prototype/testbed-android-application/build.gradle.dcl


I think it's very promising (you can check other examples, but Android one, is one of more complicated, and it's essentially a prototype of future Android plugin)

[altavir]

I will wait for Kotlin full-stack example to make any conclusions.

[gildor]

Full stack, you mean for MPP?
Yes, it would be interesting, MPP DSL even more complex than Android

[altavir]

It requires manual task dependency handling since jvm (backend) must depend on js bundle (frontend). So I will see how complex things are handled.

[gildor]

I'm sure, very limited nature of such DSL will create issues, when almost in case of any customization it will require create own plugin to wrap existing DSL

For complex things as I see, now we limited by nested structtures, pretty sure there are no references (outside of just mention something by name)

[altavir]

In my opinion, custom language is a dead end, I do a lot of things in gradle like loading things from the internet and deploy, it could not be covered in a limited language. What could be done it a set of opinionated plugins that allow to better solve specific tasks with less complexity. Some limitations of API like in @artem_zin's ketolang, but on more fundamental level (maybe wasm implementation of kotlin script) would solve security problem.

[gildor]

Well, ketolang is also custom language.

Declarative Gradle is essentially config language which looks like Kotlin, who knows what kind of features they plan to add, but it's not a programming language

[gildor]

I still see a lot of advantages of this approach, even if it limited, but if it very limited, it forces almost for any change create own DSL and own plugin

[altavir]

Like it was in Maven, yes.

[gildor]

yep

[gildor]

Infinite cycle of config -> progamming language -> repeat

[CLOVIS]

Don't forget: the publicly announced goal of Amper is to avoid having to execute build files for the IDE to understand the project. They can't achieve this goal with a turing-complete language.

[gildor]

Yep, it's the largest thing for me personally, which honestly one of mist impactful for large heavily-modularized projects

[gildor]

Declarative Gradle already have some areas of potential tooling integration:
https://github.com/gradle/declarative-gradle/blob/main/unified-prototype/unified-p[…]tal/android/application/StandaloneAndroidApplicationPlugin.java

So allows external tooling to know name and type of static DSL decalration, so it can be used for code completion of files without actual configuration, tooling need to know only list of applied plugins

[gildor]

@altavir About Full-stack web service, I feel that it indeed must be a convention plugin, a feature of Ktor, or just an additional plugin to cover this case, if such thing would exist, you wouldn't be limited by very basic config language

In our projectg we have no logic anymore in our 500+ modules, everything is plugin, build.gradle.kts are just configs, I already see that we can easily migrated to declarative gradle

[altavir]

Indeed, I also have my own set of plugins that covers almost all aspects of KScience ecosystem. But "declarative" gradle won't add anything because applying those plugins is already quite compact.

[gildor]

I don't think that declarative could add anything in terms of compactnes for build.gradle.kts for opinionated plugins, they already minimalistic
The only positive thing which I see it unifies declarations, now there are two common approaches:
1. apply convention plugin + optional dsl
2. a single plugin appleid to all modules and expose custom dsl with enable features (similar to decalarative gradle approach)

I think it settles this case, so it will be only custom DSL without declaring plugins on gradle files

Though better tooling is what I hope for, ability to add module and have working IDE without need to wait for configuration completion is a huge thing for us

[artem_zin]

Sorry just saw the mentions, I’m happy to chat with JB (@Maria Krishtal) & community about pros & cons of Starlark in Bazel & Buck compared to Kotlin & Groovy in Gradle.

I think it is essential for reproducible build system to have modern, compiled, statically-typed, side-effect-less configuration language and Kotlin can definitely be turned into that if needed as mentioned above: see https://github.com/buildfoundation/ketolang for an example of such dialect of Kotlin.

I also think it is extremely important to differentiate a dialect from a new programming language in case of Kotlin because the tooling, IDE support, etc will mostly “just work ™️ ” for a dialect of Kotlin with K2 compiler plugin architecture.

[gildor]

I feel that both Gradle and JB do not concider this, because Gradle went path of essentially static Kotlin-like config language for Declarative Gradle (at least for now), Amper is even further with Yaml
But config language is one of the most important parts of those initiatives IMO, considering how many different requirements needed to be covered with it

[CLOVIS]

But config language is one of the most important parts of those initiatives IMO

I'd go further… from what we have seen, this is the only thing these initiatives have shown us anything about.