Gradle Kotlin vs. Groovy DSL (side-by-side comparison)

Рет қаралды 7,666

Күн бұрын

Is the Gradle Kotlin DSL any good? Find out with this side-by-side comparison between the Kotlin & Groovy DSL. You'll learn the main differences as we create a Gradle project in both languages at the same time.
🚀 FREE QUICK-START GRADLE GUIDE tomgregory.com/gradlequickstart
🔥 ULTIMATE GRADLE BUILD BIBLE tomgregory.com/gradlebuildbible
Quick access to differences in Kotlin DSL:
0:00 Introduction
0:21 Different build file name
0:40 Improved plugins syntax & autocomplete
1:25 Different syntax to set task properties
1:45 Different register task syntax
2:05 Use equals to set class variables
3:02 Configuring jar task
3:25 Double quoted strings
4:05 Always use brackets
4:42 No build script warnings in IDE
CORRECTION
In Groovy it's better to use "tasks.named('jar')" instead of "jar" when configuring the jar task. That way you will avoid potential unnecessary configuration.
📖 Check out the accompanying article "5 reasons to switch to the Gradle Kotlin DSL" tomgregory.com/gradle/5-reaso...

Пікірлер: 24

@TomGregoryTech 2 жыл бұрын

►► Getting started with Gradle just got much easier. Check out my FREE Get Going with Gradle course → gradlehero.com/courses/get-going-with-gradle

@SirWolf2018 3 жыл бұрын

I don't think many people get Groovy, because it's like Perl in a way that you got so much freedom to choose how you want to express your code, which is both an advantage (if you know what you are doing), and a disadvantage (when you aren't familiar with the language and you actually work in a team). What I mean is, you call the "method" `group` in one line without parentheses, and then call `classpath` with a parentheses right on the next line! One should pick a style and stick to it in the same context. The point of the Groovy DSL of Gradle was that you can configure things in a readable way. Ceremony is like too much noise, so the Gradle DSL prefers to drop punctuations where possible. Sadly that doesn't work out so well for certain lazy property implementations: while single-item properties can be set as before, collections have become less Groovy-like. (Gradle devs reason this with not adding too much complexity to the DSL, which is kind of understandable, but was Groovy ever easy with the too much degree of freedom? Now we are actually breaking the root design goals.) And in Kotlin, you explicitly have to call `set`, which is even worse IMO. *Edit:* At the same time, I like Kotlin's rigidness. I had too many debates over code style with novice Groovy users. Not fun at all.

@caffeinejavacode1475 3 жыл бұрын

What is the shortcut on mac? Ctrl+Shift+O

@TomGregoryTech 3 жыл бұрын

Sorry but I'm not sure. If you hover over the small "Load Gradle Changes" icon that appears when you make changes to the build script, it will tell you.

@meryplays8952 7 ай бұрын

+1 to Kotlin for being self documenting by using types and +1 for being type-safe

@jozeftokarski1718 2 жыл бұрын

For me, the WORST part of Gradle Groovy DSL is that it's not pure Groovy. For example, it allows something like this: task myPrintDate(type: Exec) { commandLine 'cmd', '/c', 'date /t' } which is not a valid Groovy code. It was probably meant to make it concise, but in reality, caused a lot of confusion. If Kotlin DSL is free of that "enhancements" this is a huge +1 for Kotlin DSL.

@guai9632 2 жыл бұрын

I believe that IS a valid groovy code, just bit cryptic. I assume that there is a methodMissing defined which converts myPrintDate(type: Exec) to something like [name: 'myPrintDate', type: Exec], and then it is being passed to `task` along with the lambda

@trejkaz 2 жыл бұрын

It's not entirely free of that sort of magic, but it's relatively less common. One example you might run into: dependencies { "implementation"("com.example:widgets:1.0") } If you happened to apply the java plugin without using the plugins block, then the implementation() method won't be defined, so you end up having to invoke a string instead. This can also be seen if you define your own configurations in the build script. How does it work? The DependencyHandler block adds an extension method String.invoke(...), which then gets called when you try to invoke the string. The difference from Groovy, of course, is that this is statically compiled, so IDEA knows that it's possible to do this inside a dependencies block. Much better than Groovy, where a syntax error can sometimes remain in the code unnoticed for months until someone tries to run a particular task which evaluates the code.

@samuelpope7798 2 жыл бұрын

Well its May 2022 and gradle tutorials for beginners using the kotlin DSL are as rare as hen's teeth so as a student/beginner I'll be learning groovy DSL which seems silly because I will mostly be using gradle for android projects in kotlin in android studio an ide made by the same folks that made kotlin in the first place....wtf? Guess which DSL language I will prefer using if I ever get a job in the future.

@leandafer 2 жыл бұрын

The argument for 3 points to kotlin is... "I prefer this way" . Rsrs. Wel, Il prefer to write less! Kkkk

@aufdem2 3 жыл бұрын

+1 to Kotlin for having only one way to use quotes? Huh?

@TomGregoryTech 3 жыл бұрын

Better than Groovy where you can use single or double quotes for strings IMHO

@aufdem2 3 жыл бұрын

@@TomGregoryTech There's actually like 6 different types of quotes you can use in Groovy. I'm a big fan of dollar slashy strings. I'm having a hard time wrapping my head around why that's an issue, especially when you could just use double-quotes in every case, and escape when necessary - just like Kotlin. Of course, I am a Groovy fanatic, so it may be lost on me. ;)

@SirWolf2018 3 жыл бұрын

@@aufdem2 I've experienced some corner cases when GString to String conversion does not happen as one would expect, for example when passing string arrays (auto-converted from lists) to a Java method. So in Groovy, using single quotes where possible is actually helpful, plus check out groovy-lang.org/style-guide.html

@trejkaz 2 жыл бұрын

@@SirWolf2018 Yes. You hit this in Jenkins pipeline scripts all the time too. If you have a method which takes String, sometimes trying to pass in a GString just outright fails, and you're forced to use toString() on it, even though you thought you already had a string. I think the way Groovy did these was less than ideal - I would have preferred them not to have a separate class for those. But of course, Groovy GStrings are lazily evaluated, a feature which is only possible because it does have its own class.

@SirWolf2018 2 жыл бұрын

@@trejkaz Right. By the way, instead of `.toString()` I often write `as String` as a more readable conversion.

@SirWolf2018 3 жыл бұрын

Impressive, docs.gradle.org/current/userguide/migrating_from_groovy_to_kotlin_dsl.html explains that `tasks.jar` is indeed the Kotlin equivalent of `tasks.named('jar')` in Groovy. I didn't know that, although I had to look up, I wish you had explained it instead (and a little sooner than later showing that `tasks.jar` is a `TaskContainer`, because I was already scratching my head by that time. As for next, you configure the `jar` task in Groovy without the configuration avoidance API, which is inconsistent. If you follow consistency, then I believe Groovy would have gotten 1 less points. :)

@TomGregoryTech 3 жыл бұрын

Good spot. Task configuration avoidance I probably should have mentioned, although it adds complexity for those new to Gradle. I will add some notes to the video. Thanks for the pointers!

@trejkaz 2 жыл бұрын

@@TomGregoryTech Task configuration avoidance is a whole video in its own right. People new to Gradle (including practically every other dev at work) don't watch out for it when defining new tasks, so the build gets slower and slower, and then people ask _me_ why the build is slow. I really wish Gradle had some way to straight-out _assert_ that no tasks had been created at the end of script evaluation, so we could finally bring the hammer down on idiots who create their tasks eagerly. But of course, we can't currently do that, because Gradle _itself_ creates some things eagerly. Published artifacts spring immediately to mind.