https://kotlinlang.org
Join Slack
After migrating my `kotlin-dsl` Script Plugin out of a `gradle.kts` file into a normal `.kt` file, I...
# gradle
h
After migrating my 
kotlin-dsl
Script Plugin out of a 
gradle.kts
file into a normal 
.kt
file, I am saving ~55 seconds in the configuration phase under "Building included plugins." NOTE: This is using the "Multiplatform Plugin" (see below post, but with JVM Only it still saves ~15 seconds) Code & Gradle Build Scan Links: https://github.com/handstandsam/ShoppingApp/pull/58
👌 3
⚡ 2
This is with Kotlin 1.6.20 (because that's the highest supported by Jetpack Compose). And, this does apply the Multiplatform Plugin. I can try to do this without any multiplatform and see if there is as much of a difference 🤔
v
Just for your clarity. "convention plugin" just means a plugin that applies your conventions, not how it is implemented plugins in 
....gradle.kts
files are either called "script plugins" if applied with "apply from", or "precompiled script plugin" if they reside in 
buildSrc
or an included build. "convention plugins" are often implemented as "precompiled script plugins", but those are not synonyms. And that 
kotlins-dsl
enables precompiled script plugins is just one detail, it does more, so even without precompiled script plugins but with conventional Kotlin plugins it might be useful. 🙂
h
Ahh, "Script Plugin" it is then. In this case it would get included, but is a clean build, so it has to be built anyways. Thanks for the clarification on terminology!
v
"Script plugin" or "precompiled script plugin"? 🙂 I'm curious where you see the bad performance, even if I cannot do anything about it.
h
If you click on the images of the build scans, you can see them in that PR.
I linked to them for reference. It's hard to trace down without those sort of details, so I carefully collected that data. https://github.com/handstandsam/ShoppingApp/pull/58 Before: https://scans.gradle.com/s/oaxg4ue3snzua/performance/configuration After https://scans.gradle.com/s/yct4cpiwwqpy4/performance/configuration
v
Ah, so "precompiled script plugin", yes, thx
h
Yes, however in this case, because it's the first build, it technically is a 
Precompiled Script Plugin
, but it's being compiled the first time 😂 , so a "not yet compiled pre-compiled script plugin"?
v
No, still a "precompiled script plugin". It is "precompiled" while the included build is built, opposed to evaluated dynamically like a script when applying with 
apply from
. That you probably build on ephemeral build agents and do not use the task output cache is unlucky of course in terms of build time, especially if there is really such a worse performance.
🆒 1
h
Do I call the plugin in 
.kt
a "Precompiled Plugin" then?
v
No, it is just a regular binary plugin implemented in Kotlin. Any Kotlin file needs to be compiled before being used. A Kotlin Script file can be interpreted dynamically at runtime using the script runtime, or it can be precompiled, so that it is already there as 
class
file and does not need to be interpreted dynamically each time it is used.
Btw. if you look at the timeline view of the build scans it seems to indeed be the price you have to pay for the nicer syntax while always doing a clean build. Not sure whether this is expected or you should open an issue about it. But I guess that's just how it. Using Kotlin DSL is in most situations slower than using Groovy DSL for the build scripts, but that's just the price you have to pay for getting much more confidence and amazing IDE support. And as long as it is just on a CI system or on clean build, I personally don't care about the slightly slower build for having much better dev experience. 🙂
h
I like the Kotlin auto-complete, but if you look there, it's written in Kotlin, and still really nice, just not using 
.gradle.kts
but using 
.kt
instead. So, not using 
.gradle.kts
for a Precompile Script Plugin seems like the winner to me.
👌 1
m
Looks like "script plugin" needs to be added to https://github.com/autonomousapps/gradle-glossary 🙂
h
👍 1
🙏 1
v
Just scroll down to "S"?
m
Oh my how did I miss this 🙃
Too many 'scripts'
I guess we can close it @handstandsam , sorry for the noise
h
Closed, I blame it on you @mbonnin, but then also blamed myself.
🤝 1
cheers
😄 1
j
but with normal plugins you lose the dsl, no?
h
v
The shipped / hard-coded DSL parts are still available as long as you apply the DSL plugin or manually add the DSL dependency. You mainly miss the generated accessors from applied plugins.
👍 2
23 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by