About an year ago when I first discovered the Gradle Kotlin DSL, I was very quick to jump on that train. Now it feels like a mistake.
The initial ...
For further actions, you may consider blocking this person and/or reporting abuse
Hello Harsh,
I can relate to your pain points.
But I want to point out that you are making a confusion.
It's a bit the same confusion I wrote about here
Kotlin is not Android
Jean-Michel Fayard π«π·π©πͺπ¬π§πͺπΈπ¨π΄ γ» Oct 28 '19 γ» 3 min read
Gradle is a bit like SchrΓΆdinger's cat.
What's the difference?
So when you write:
Actually what you meant is that the Android Framework team doesn't seem to have invested any actual time...
And I can guarantee you it's not an impression.
Well they have pretended they did something in a canary release
But don't believe it, it's a lie.
1) The Android Gradle plugin does not publish the plugin artifacts to google() repository, necessary for the plugins block to work out of the box issuetracker.google.com/issues/645...
2) The documentation does not include Kotlin snippets unlike most other Gradle plugins github.com/gradle/gradle/issues/6790
3) Adding a module within Android Studio breaks my build. I just tested with 4.0 RC, it still breaks my build by adding settings.gradle files and so on. It would be nice if they stopped breaking the build.
1) is the reason why you find this so frustrated with this commit. It has nothing to do with Gradle+Kotlin per se and everything to do with the Android Framework team having not done their homework.
github.com/msfjarvis/viscerion/com...
3) is such an obvious bug that I'm pretty sure that no-one in the Android team is using Gradle+Kotlin.
Which is why you have those pain points.
TL-DR: Kotlin is the future of Gradle, and also the present of Gradle if you are not doing on Android. But since the Android team has done nothing at all, using it on Android now has rough edges.
I agree that my perspective is very skewed because I mostly use Gradle for Android and the AGP/Android toolkit team has not been very proactive. But many of these problems still carry over to non-Android JVM projects I've worked on. The build times are still noticeably slower than Groovy and the code complexity arising from every plugin author not being able to afford being proactive in migrating their codebases. I really, really enjoy working with Kotlin and I would love to be able to write everything in Kotlin but as Howard Stark would say ;)
Yes but fixes are coming.
A pain point for me in IntelliJ IDEA is that auto-completion in
build.gradle.kts
, while great, is also quite slow.Well, once Kotlin 1.3.60 is released, it is supposed to be 3 times faster.
This is also a problem that can be solved... but only if tackled properly. Talking about performance in general is nonsense.
What you should do a Gradle Build Scan and check there is nothing wrong with your build configuration and see what metrics do you have.
The one Gradle trick that supersedes all the others
Jean-Michel Fayard γ» Sep 22 γ» 3 min read
That's great to hear.
I have. My configuration had no bottlenecks, Kotlin just took longer to compile than Groovy, and the build scan results for the tasks after the initial compilation of configuration files were nearly identical.
I've taken most standard measures to maximise system performance, I disabled Spectre and Meltdown mitigations on my AMD machines, I've disabled all daemons and services I don't require.
I've tried with and without Gradle build cache and the results have not changed, once configured with the Kotlin DSL, there is a noticeable if not significant degradation in build times.
I wonder, are you using the
buildSrc
and modifying it frequently?Not using buildSrc on this particular project. Used it extensively on the Android project where I got 5 to 10 seconds of slowdowns. I don't modify it during most iterative development, only for dependency updates and version bumps where I don't use or build from an IDE.
Ah ah, that part looks very familiar.
In this project you are using my old plugin
de.fayard.buildSrcVersions
I noticed exactly the same problem as you: modifying
Versioons.kt
is not great because it basically forces a clean build every time.Instead I am now working on
de.fayard.refreshVersions
that does the same thing, but extract the versions not in code (inside thebuildSrc
) but in a proper format (that can be read and written by tools) so that we don't pay the penalty price on each update.See github.com/jmfayard/buildSrcVersio...
Subscribed to the issue :)