https://kotlinlang.org logo
#gradle
Title
# gradle
h

hfhbd

11/23/2023, 10:14 AM
How does the new amber project to reduce complexity of the KGP plugin align with the removal of the very easy to use kotlin-js plugin, from a user perspective?
b

Big Chungus

11/23/2023, 10:17 AM
OPINION: Removal of kjs plugin allows consolidating the dev effort and documentation on a single way of doing things which also happens to be reusable for other kotlin targets. I personally am happy for it being removed as it simplifies debugging issues reported by people since you don't need to check if it only works on one of the two plugins - everyone uses the same one now.
2
Plus kmp plugin with only js target only differs from js plugin in naming of gradle entities. The configuration is exactly the same.
h

hfhbd

11/23/2023, 10:19 AM
While it is true regarding Kotlin/MPP, the Kotlin/JS configurations are exactly like the Kotlin/JVM ones, which won't be removed.
b

Big Chungus

11/23/2023, 10:20 AM
Are you referring to the top level dependencies block?
h

hfhbd

11/23/2023, 10:20 AM
yes, for example
b

Big Chungus

11/23/2023, 10:20 AM
Yeah, that's probably the only meaningful difference between the two
c

CLOVIS

11/23/2023, 10:21 AM
My own opinion: the removal of the kjs plugin is welcome. It means JetBrains will support single-platform projects in the KMP plugin, which means I can finally configure all projects with the KMP plugin instead of having to figure out the differences between each platform. Since then, I only use the KMP plugin, no matter the supported platforms (even for pure JVM projects).
same 3
plus1 2
h

hfhbd

11/23/2023, 10:31 AM
I agree to the simplifying, especially if you use non jvm/js targets in your project. And removing the kotlin-js plugin allows you as a build/gradle plugin author to only check Kotlin/MPP and Kotlin/JVM. But from user perspective, migrating from Kotlin/JS to Kotlin/MPP adds additionally complexity compared to Kotlin/JVM. For consistency, removing the Kotlin/JVM plugin would be the next step 🤷‍♂️
c

CLOVIS

11/23/2023, 10:34 AM
For consistency, it would, but it's not going to happen anytime soon. Most devs already dislike Gradle quite a bit, and most companies using Kotlin haven't even started considering KMP… It would be a very scary move for them to announce something like that
b

Big Chungus

11/23/2023, 11:05 AM
Yeah, as much as I'd like to see jvm and android plugins gone in favour of kmp plugin, sadly it's just not realistic.
c

CLOVIS

11/23/2023, 11:08 AM
Well, I just don't use them. Whether they exist or not means more or less work for JB, but it doesn't really impact me directly.
b

Big Chungus

11/23/2023, 11:09 AM
It kinda does - they take dev time from kmp plugin as well as introduce fragmentation in community docs
👍 1
1
Granted, that's not anything substantial
v

Vampire

11/23/2023, 11:11 AM
> Most devs already dislike Gradle quite a bit That's simply not true. Most devs I know like Gradle quite much. Except maybe if they try to combine KMP, AGP, and Compose. 😄 The haters just have louder voices.
👆 6
💯 3
👆🏾 1
j

Javier

11/23/2023, 11:11 AM
My opinion is: • I don’t like amper at all as it uses Yaml. I would like GitHub Actions could use Kotlin DSL as JetBrains Space does and seeing we running away in builds to Yaml is really sad. I hope they reconsider using Yaml to use Kotlin DSL even if is a wrapper over Gradle. • Kotlin should remove all plugins and keep only one, the KMP one, which can cover all use cases.
v

Vampire

11/23/2023, 11:14 AM
You know that you can write your GitHub Action workflows in Kotlin, yes?
j

Javier

11/23/2023, 11:14 AM
I know, but I was meaning the official way to consume them
v

Vampire

11/23/2023, 11:15 AM
Yeah, GitHub at least misses 1st class support for 3rd party DSLs still
c

CLOVIS

11/23/2023, 11:15 AM
Well, maybe it's different where you are, but most devs I know dislike Gradle. I'm not saying it's warranted, though—most things people complain about are things the Gradle docs says not to do, or things that are deprecated. w.r.t. Amper, I agree. I think it's strange that JB is doing their own thing on their side, which is different from the Gradle team's improvements. It feels like they are planning for dropping Gradle entirely once Amper is powerful enough, and I doubt that can ever happen.
j

Javier

11/23/2023, 11:15 AM
Gradle plus Kotlin is enough powerful to avoid any limitation a GitHub Action based on Yaml can have
It will be really sad you can’t even do a simple
if/else
in the combination of github actions with yaml and amper and “duplicating” if conditions to get that simple behavior
v

Vampire

11/23/2023, 11:17 AM
Gradle plus Kotlin is enough powerful to avoid any limitation a GitHub Action based on Yaml can have
Yeah, I also prefer doing all logic in the build tool and not be tied too deep to the CI that I am currently using to stay flexible. But for testing my GitHub Action, there is not much other choice and there I have quite some complexity. :-D
👍 4
j

Javier

11/23/2023, 11:19 AM
Dropping Gradle to a solution based on Yaml is… bad_word
c

CLOVIS

11/23/2023, 11:19 AM
I'm really surprised they went the Amper route before simplifying the existing Gradle plugin
2
j

Javier

11/23/2023, 11:21 AM
Or creating its own build system based on Kotlin DSL as they did for its CI
v

Vampire

11/23/2023, 11:21 AM
I'm really surprised they went the Amper route before simplifying the existing Gradle plugin
Different teams probably 😄
j

Javier

11/23/2023, 11:49 AM
I hope the new initiative about Gradle declarative plus the cleanup of APIs in Gradle 9 allows Amper becomes unnecessary for simple projects.
c

CLOVIS

11/23/2023, 11:50 AM
Same. But it's a shame that we're wishing for this new attempt to be useless so soon after it was announced.
b

Big Chungus

11/23/2023, 11:52 AM
I'm still baffled why they couldn't just make amper a regular gradle plugin that you configure in its own block at root project
c

CLOVIS

11/23/2023, 11:53 AM
The only explanation I can come up with is that they're planning long-term to entirely remove Gradle and make their own build system, they're just using it as a backend for now to prioritize the syntax
b

Big Chungus

11/23/2023, 11:54 AM
Even then, amper block in build.gradle.kts could be implemented without any gradle primitives and later be just ported to amper.kts
🤷‍♂️ 1
c

CLOVIS

11/23/2023, 11:55 AM
I hope that's not the case though. I think “cleaning up Gradle” has a lot more future than “start a new build system from scratch”
1
b

Big Chungus

11/23/2023, 11:55 AM
With an added benefit of simpler future project migration (rename buildfile and remove plugins block)
Kotlin without gradle/maven plugin ecosystem is like js without npm ecosystem...
j

Javier

11/23/2023, 11:56 AM
You can abstract anything from Gradle to being able to write exactly the same as you write in Yaml but in Kotlin, so the toy/tutorial apps can get that simplicity, and the complex apps can scale well as they are backed by a real language.
👍 2
b

Big Chungus

11/23/2023, 11:57 AM
Anyways, it's just an experiment for now so let's not speculate too much 😄
j

Javier

11/23/2023, 12:03 PM
Just an example of a DSL that does tons of things, but it is declarative and easily readable (obviously names can be improved).
Copy code
customDSL {
    config {
        analysis() // config Sonar/Detekt
        coverage() // config Kover
        documentation() // config MkDocs and Dokka
        format() // config spotless
        publishing() // config publication to maven central
    }
    kotlin {
        // This block could be used to add features from Kotlin/Kotlinx
        // in an official DSL
        features {
            coroutines()
            explicitApi()
            serialization(json = true)
        }

        common()
        apple {
            ios {
                ...
            }
            macos {
                ...
            }
            tvos {
                ...
            }
            watchos {
                ...
            }
        }
        jvm()
        linux {
            ...
        }
        mingw {
            ...
        }
    }
}
👍 1
💯 1
c

CLOVIS

11/23/2023, 1:11 PM
I mean, as soon as you start making plugins, your build can look however you want: https://gitlab.com/opensavvy/playgrounds/gradle/-/blob/main/core/build.gradle.kts?ref_type=heads
I think JB could go a long way by just simplifying the existing plugin
e

eygraber

11/23/2023, 5:21 PM
Yeah, as much as I'd like to see jvm and android plugins gone in favour of kmp plugin, sadly it's just not realistic.
I think one of the JB engineers mentioned a while ago that this is a goal they're working towards (maybe not Android, but JVM)
t

tapchicoma

11/23/2023, 9:20 PM
it was Roman Elizarov 🙂
e

eygraber

11/23/2023, 9:22 PM
Is that still the plan?
t

tapchicoma

11/23/2023, 9:25 PM
Overall yes. Though not in the near future, KMP plugin is much more heavy then Kotlin/Jvm and imho we need to made it more "pluggable". Kotlin/Android may be gone in the next year.
🎉 1
👀 1
g

gildor

11/24/2023, 10:09 AM
and android plugins gone in favour of kmp plugin, sadly it's just not realistic
Kotlin/Android soon will be gone, it will be a part of Android Gradle Plugin: https://issuetracker.google.com/issues/259523353
🎉 1
b

Big Chungus

11/24/2023, 10:23 AM
Nice, the dream is still alive then!
g

gildor

11/24/2023, 10:25 AM
> I'm really surprised they went the Amper route before simplifying the existing Gradle plugin @CLOVIS Have you read Amper FAQ? The reason for Amper is not only simplification of configs, but also experimenting with making it static to improve IDE experience, and it a lot more important for medium-large projects than any configuration simplification, larger projects anyway move all logic to custom gradle plugins and do not work with default DSL anyway Also why be surprised by this, when Gradle themselves planning to do exactly the same: https://blog.gradle.org/declarative-gradle Though, I should admit, attempt to make some static Kotlin DSL sounds a bit strange, but infinitely better than yaml, will see what they will do for prototype Making IDE experience for large projects better is indefinitely more important for large projects than any simplification of hello world projects
c

CLOVIS

11/24/2023, 10:26 AM
> Also why be surprised by this, when Gradle themselves planning to do exactly the same: > https://blog.gradle.org/declarative-gradle I'm surprised because it's two different things. I'm not surprised by Gradle experimenting with this, I'm surprised by JB doing something else on their side.
g

gildor

11/24/2023, 10:26 AM
Because Gradle is known for their extremely slow pace of changes, I believe they want experiment now, not wait next year for some kind of prototype
c

CLOVIS

11/24/2023, 10:27 AM
Fair
t

tapchicoma

11/24/2023, 10:31 AM
I would say there are two parallel initiatives to improve import in the Gradle (they are complimentary to each other): • this declarative Kotlin DSL • and another one is staging sync where IDE will try to get partial project information as soon as possible to allow users interact with the project itself almost right after open. And then in the background gradually load other information to expand IDE information about the project
😮 1
g

gildor

11/24/2023, 10:32 AM
Dropping Gradle to a solution based on Yaml is… bad_word
Well, gradle is not dropped, Amper is a gradle plugin (so far) And let's be honest, Kotlin DSL is improvement in terms of usability for Gradle, but it is still very far to be good and nice, it's still more like framework to configure gradle than real DSL
1
t

tapchicoma

11/24/2023, 10:33 AM
ah yeah - project isolation should also improve import part as well
1
b

Big Chungus

11/24/2023, 10:35 AM
Gotta give credit where credit is due - default hierarchies feature in 1.9.20 went a long way in simplifying the config already
c

CLOVIS

11/24/2023, 10:37 AM
Ahah yeah. I've been using the Kotlin Gradle DSL since 2017 or so, and it's amazing how much it improved
14 Views