https://kotlinlang.org logo
#announcements
Title
# announcements
m

Maria Krishtal

03/07/2024, 1:46 PM
📢 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
2
🫠 2
7
K 25
🐕 1
👍 5
m

mbonnin

03/07/2024, 4:30 PM
I didn't even know
maven(dependencyNotation)
was a thing. Or is it?
Copy code
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.
a

altavir

03/07/2024, 4:39 PM
This is not plain gradle. This is some kind of hypothetical "improved" thing.
👍 1
👍🏾 1
m

mbonnin

03/07/2024, 4:45 PM
👍 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.
1
a

altavir

03/07/2024, 4:48 PM
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.
💯 3
12
c

CLOVIS

03/08/2024, 9:19 AM
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.
👍 4
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.
same 1
v

vladimirsitnikov

03/08/2024, 4:23 PM
If "exported" is a boolean for "api vs implementation", then how do they suggest modelling compileOnly/compileOnlyApi? Exported=true/false/compileOnly/compileOnlyApi? :)
☝️ 3
c

CLOVIS

03/08/2024, 4:26 PM
Some examples had an additional
scope = runtimeOnly
argument, which I understand as the remplacement for everything other than api/implementation.
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.
a

aurelien

03/09/2024, 1:57 PM
I have completed the survey, and I must say it is totally biased towards readability...
2
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.
💯 2
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.
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.
8
a

altavir

03/10/2024, 6:49 AM
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.
3
g

Gleb

03/10/2024, 9:53 AM
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
d

Darryl Miles

03/10/2024, 5:48 PM
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.
g

gildor

03/11/2024, 9:59 AM
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)
6
c

CLOVIS

03/11/2024, 10:13 AM
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.
💯 3
r

Robin T

03/13/2024, 11:01 AM
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
Copy code
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:
Copy code
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.
c

CLOVIS

03/13/2024, 12:39 PM
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.
d

Darryl Miles

03/13/2024, 1:54 PM
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.
1
c

CLOVIS

03/13/2024, 2:03 PM
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.
m

Marcin Wisniowski

03/19/2024, 2:03 PM
> 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.
d

Darryl Miles

03/19/2024, 10:56 PM
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.
g

gildor

03/20/2024, 5:51 AM
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"
m

marlonlom

03/29/2024, 4:11 PM
@Maria Krishtal Done 👍 🙂
🙌 1
e

edrd

04/01/2024, 12:59 PM
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.
g

gildor

04/02/2024, 6:45 AM
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
👀 1
e

edrd

04/02/2024, 1:18 PM
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.
68 Views