Developer first Gradle builds - Sterling Greene, Paul Merlin

Recording brought to you by American Express. americanexpress.io/kotlin-jobs
In the ever-evolving landscape of software development, the efficiency of build systems plays a pivotal role in project success. Part of our vision for Gradle is to deliver an elegant and extensible declarative build language that allows developers to describe any kind of software in a clear and understandable way. Our current effort is described in blog.gradle.org/declarative-g....
This session delves into the challenges faced by developers when understanding and maintaining complex build scripts and demonstrates an innovative approach that harnesses the expressiveness of Kotlin while imposing restrictions to enhance clarity and maintainability. Attendees will gain insights into the rationale behind adopting a declarative paradigm for build definition and the benefits it brings to project workflows.
Key topics covered include:
Declarative Build Principles: Understand the advantages of a declarative build language and its impact on project maintainability, readability, and collaboration.
Expressive DSL: Explore the capabilities of the DSL and how it serves as a powerful tool for expressing build configuration concisely.
Impact on projects: Explore case studies of projects that use a declarative build language, showcasing improvements in build performance, understanding, and maintenance.
By attending this session, software developers and build engineers will leave with practical insights and knowledge about crafting a more maintainable, expressive, and declarative Gradle build definition.
#kotlin #kotlinconf #gardle

[@aliakbarmostafaei]

Great! Yet another new thing to learn / migrate to in Android dev.

[@GeorgeC-ur9yw]

One more thing to deprecate

[@cromefire_]

​@@GeorgeC-ur9ywWell the kotlin script isn't going to be deprecated, you do need that for more advanced stuff.

[@roudikk]

I thought Amper was suppose to be the next build system for kotlin projects?

[@schlaubi]

Like decorative Gradle, Amper is an experiment, also they have different goals, Amper mainly tries to be a KMP build tool, whilst hardly supports more types

[@cromefire_]

Also Amper just runs on top of Gradle as well

[@SB-gc8wf]

Serious question. Why should I actually use another programming language when everything I want to express in it is declarative? Wouldn't it be easier to use one of the many available configuration languages? Please don't get me wrong. So far, I have been very satisfied with Kotlin as the Gradle DSL, but I am finding that everything is becoming too abstract. As a developer, I ideally want to set up my build once and then focus on my domain-specific work. Unfortunately, in recent years, I have seen many of my developer colleagues turn away from Gradle in frustration. Gradle is too complex and often just gets in the way. Unfortunately, there is no reasonable alternative. Maven, on the other hand, is too rigid and poorly documented. I believe the approach shown in this presentation is wrong. It should be less abstract and much more transparent.

[@krellin]

i hate gradle, as soon as there is a sane replacement that is not made in a joke of a language i'll dump it right away the amount of times that common sense things didnt work and i had to spend unreasonable amount of time just to settle for a hack is crazy

[@lppedd]

This was the same sentiment I had when I did not have enough experience with Gradle. The only way to master Gradle is to read its documentation start to finish and to use it daily, experimenting. I lead devops now and I get to mess with multiple build systems, and let me tell you that Gradle is actually pretty neat compared to other solutions. Most devs are used to *dependency management* tools, and so they see Gradle just as a dependency manager. That's where the biggest issue is.

[@schlaubi]

Yeah like 5 yrs ago, when I first touched Gradle and the Kotlin DSL was brand new. i very much hated it, a lot has changed and improved since then and after understanding how it works I started to love it, any other build system started to become a limiting factor for me. Many people yell at Gradle for being complicated, but it's really not once you spend some time to understand it, Gradle gives you the flexibility of makefiles but is way easier to use

[@Mglunafh]

I wish gradle had a better learning materials for the complete beginners. When i started learning it, the first page of introduction was about tasks, "hey, let's create a task which prints helloworld, then another task, then chain them" or smth this basic, and the second or third page was full blown ass java build project with buildscripts / plugins / dependencies, bunch of options, and all these concepts, objects, tasks or whatever it is came out of absolutely nowhere! Where to look at the task structure, task options, how to inspect execution graph, how to mangle it -- no easy answers, you are for all intents and purposes forced to copy-paste this code for your starting java project as an act of faith. They explain how this build process works, but i could imagine they would just state "gradle hires magical gnomes that carry your files around" and beginners wouldn't disprove it without digging around an unknown amount of time. Gradle is a powerful tool, but without learning it resembles a giant leaky abstraction, and it takes a lot of time and frustration to unlock Gradle potential, at least i didn't find an efficient way -- would appreciate a lot if anybody shares one! -- only a thorny path of trial and error. Oh, and thank god they introduced kotlin DSL, messing with groovy was unbearable!