Update from Forestry.io
Harsh Shandilya updated content/posts/why-i-went-back-to-the-gradle-groovy-dsl.md
This commit is contained in:
parent
5bf643593f
commit
ad2820b396
|
@ -18,7 +18,7 @@ fields:
|
|||
name: categories
|
||||
label: categories
|
||||
pages:
|
||||
- content/posts/teachingkotlin-kotlin-for-android-java-developers.md
|
||||
- content/posts/teachingkotlin-part-1-classes-and-objects-and-everything-in-between.md
|
||||
- content/posts/teachingkotlin-part-2-variables.md
|
||||
- content/posts/why-i-went-back-to-the-gradle-groovy-dsl.md
|
||||
- content/posts/teachingkotlin-part-2-variables.md
|
||||
- content/posts/teachingkotlin-part-1-classes-and-objects-and-everything-in-between.md
|
||||
- content/posts/teachingkotlin-kotlin-for-android-java-developers.md
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
+++
|
||||
categories = []
|
||||
date = "2019-10-26T01:53:00+05:30"
|
||||
date = 2019-10-25T20:23:00Z
|
||||
draft = true
|
||||
slug = "why-i-went-back-to-the-gradle-groovy-dsl"
|
||||
tags = []
|
||||
|
@ -9,4 +9,131 @@ title = "Why I went back to the Gradle Groovy DSL"
|
|||
+++
|
||||
About an year ago when I first discovered the [Gradle Kotlin DSL](https://docs.gradle.org/current/userguide/kotlin_dsl.html), I was very quick to [jump](https://github.com/msfjarvis/viscerion/commit/c16d11a816c3c7e3f7bab51ef2f32569b6b657bf) [on](https://github.com/android-password-store/Android-Password-Store/commit/3c06063153d0b7f71998128dc6fb4e5967e33624) [that](https://github.com/substratum/substratum/commit/ebff9a3a88781d093565526b171d9d5b8e9c1bed) [train](https://github.com/substratum/substratum/commit/5065e082055cde19e41ee02920ca07d0e33c89f5). Now it feels like a mistake.
|
||||
|
||||
The initial premise of the Gradle Kotlin DSL was very cool. You get first class code completion in the IDE, and you get to write Kotlin rather than the arguably weird Groovy.
|
||||
The initial premise of the Gradle Kotlin DSL was very cool. You get first class code completion in the IDE, and you get to write Kotlin rather than the arguably weird Groovy. People were excited to finally be able to write complex build logic using the `buildSrc` functionality that this change introduced.
|
||||
|
||||
However the dream slowly started fading as more and more people started using the Kotlin DSL and the shortcomings became more apparent. My grievances with the Kotlin DSL are multifold as I'll detail below.
|
||||
|
||||
Just a disclaimer, This post is not meant to completely trash the Kotlin DSL's usability. It has it's own very great benefits and people who leverage those should continue using it and disregard this post :-)
|
||||
|
||||
## Build times
|
||||
|
||||
The Gradle Kotlin DSL inflates build times _significantly_. Compiling `buildSrc` and all the `*.gradle.kts` files for my [app](http://github.com/msfjarvis/viscerion/tree/1ea6f07f8219aa42139977f37ebbcb230d7f78e7 "app") takes upto 10 seconds longer than the Groovy DSL. Couple that with the fact that changing any file from `buildSrc` invalidated the entire compiler cache for me made iterative development extremely painful.
|
||||
|
||||
## Half-baked API surface
|
||||
|
||||
Gradle doesn't seem to have invested any actual time in converting the original Groovy APIs into Kotlin-friendly versions before they peddled the Kotlin DSL to us. Check the samples below and decide for yourself.
|
||||
|
||||
Groovy
|
||||
|
||||
\`\`\`groovy
|
||||
|
||||
android {
|
||||
|
||||
compileSdkVersion 29
|
||||
|
||||
buildToolsVersion = '29.0.2'
|
||||
|
||||
defaultConfig {
|
||||
|
||||
minSdkVersion 21
|
||||
|
||||
targetSdkVersion 29
|
||||
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
buildTypes {
|
||||
|
||||
minifyEnabled = true
|
||||
|
||||
}
|
||||
|
||||
dependencies {
|
||||
|
||||
implementation('my.company:fancy.library:1.1.1') {
|
||||
|
||||
force = true
|
||||
|
||||
}
|
||||
|
||||
}
|
||||
\`\`\`
|
||||
|
||||
Kotlin
|
||||
|
||||
\`\`\`kotlin
|
||||
|
||||
android {
|
||||
|
||||
compileSdkVersion(29)
|
||||
|
||||
buildToolsVersion = "29.0.2"
|
||||
|
||||
defaultConfig {
|
||||
|
||||
minSdkVersion(21)
|
||||
|
||||
targetSdkVersion(29)
|
||||
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
buildTypes {
|
||||
|
||||
isMinifyEnabled = true
|
||||
|
||||
}
|
||||
|
||||
dependencies {
|
||||
|
||||
implementation('my.company:fancy.library:1.1.1') {
|
||||
|
||||
isForce = true
|
||||
|
||||
}
|
||||
|
||||
}
|
||||
\`\`\`
|
||||
|
||||
I am definitely biased here, but this is not how an idiomatic Kotlin API looks like.
|
||||
|
||||
What we should have gotten
|
||||
|
||||
\`\`\`kotlin
|
||||
|
||||
android {
|
||||
|
||||
compileSdkVersion = 29
|
||||
|
||||
buildToolsVersion = "29.0.2"
|
||||
|
||||
defaultConfig {
|
||||
|
||||
minSdkVersion = 21
|
||||
|
||||
targetSdkVersion = 29
|
||||
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
buildTypes {
|
||||
|
||||
minifyEnabled = true
|
||||
|
||||
}
|
||||
|
||||
dependencies {
|
||||
|
||||
implementation('my.company:fancy.library:1.1.1') {
|
||||
|
||||
force = true
|
||||
|
||||
}
|
||||
|
||||
}
|
||||
\`\`\`
|
||||
|
||||
Property access syntax and discoverable variable names should have been the norm since day one for it to actually be a good Kotlin DSL.
|
Loading…
Reference in New Issue