https://kotlinlang.org logo
Join Slack
Powered by
How does the new amber project to reduce complexit...
# gradle
h
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
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
While it is true regarding Kotlin/MPP, the Kotlin/JS configurations are exactly like the Kotlin/JVM ones, which won't be removed.
b
Are you referring to the top level dependencies block?
h
yes, for example
b
Yeah, that's probably the only meaningful difference between the two
c
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
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
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
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
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
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
> 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
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
You know that you can write your GitHub Action workflows in Kotlin, yes?
j
I know, but I was meaning the official way to consume them
v
Yeah, GitHub at least misses 1st class support for 3rd party DSLs still
c
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
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
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
Dropping Gradle to a solution based on Yaml is… bad_word
c
I'm really surprised they went the Amper route before simplifying the existing Gradle plugin
➕ 2
j
Or creating its own build system based on Kotlin DSL as they did for its CI
v
I'm really surprised they went the Amper route before simplifying the existing Gradle plugin
Different teams probably 😄
j
I hope the new initiative about Gradle declarative plus the cleanup of APIs in Gradle 9 allows Amper becomes unnecessary for simple projects.
c
Same. But it's a shame that we're wishing for this new attempt to be useless so soon after it was announced.
b
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
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
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
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
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
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
Anyways, it's just an experiment for now so let's not speculate too much 😄
j
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
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
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
it was Roman Elizarov 🙂
e
Is that still the plan?
t
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
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
Nice, the dream is still alive then!
g
> 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
> 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
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
Fair
t
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
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
ah yeah - project isolation should also improve import part as well
➕ 1
b
Gotta give credit where credit is due - default hierarchies feature in 1.9.20 went a long way in simplifying the config already
c
Ahah yeah. I've been using the Kotlin Gradle DSL since 2017 or so, and it's amazing how much it improved
25 Views
Open in Slack
PreviousNext
Powered by