msfjarvis
/
msfjarvis.dev
mirror of https://github.com/msfjarvis/msfjarvis.dev.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Syntax highlighting fixes 

Signed-off-by: Harsh Shandilya <msfjarvis@gmail.com>
This commit is contained in:
Harsh Shandilya 2019-11-06 11:58:53 +05:30
parent 2832918b07
commit de7df2382b
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
content/posts/why-i-went-back-to-the-gradle-groovy-dsl.md
View File

@ -11,7 +11,7 @@ About an year ago when I first discovered the [Gradle Kotlin DSL](https://docs.g
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.
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 :-)
@ -47,7 +47,7 @@ dependencies {
Kotlin
```kotlin
```groovy
android {
compileSdkVersion(29)
buildToolsVersion = "29.0.2"
@ -71,7 +71,7 @@ I am definitely biased here, but this is not how an idiomatic Kotlin API looks l
What we should have gotten
```kotlin
```groovy
android {
compileSdkVersion = 29
buildToolsVersion = "29.0.2"