We need to talk about Gradle
Вставка
- Опубліковано 16 тра 2024
- The aim of this channel is to document the working practices of a half-decent software developer, so I pretty much show all the changes that I make to the source code of a project.
There is one exception to this convention; which is that I don’t subject you to the chores that are required to keep the build up to date. I upgrade versions, fiddle to make things faster, and sometimes even upgrade Gradle itself, all on my own time.
Today though I tried to modify the build of the JetBrains Ktor example project that we have been studying in recent videos (ktor.io/docs/server-create-ht.... I just wanted to get it to build and run on JDK 21, so that I could run benchmarks with Loom virtual threads.
I failed.
As failing to get Gradle to just do something is, in my experience, part of the working practices of a half-decent software developer, I’ve decided to make an exception to my exception and publish the attempt.
I’m probably missing something obvious. Maybe I just need to RTFM? No doubt there is a solution, but the sad fact is that where Gradle is concerned, even my 35 years of industry experience isn’t enough to keep me from stumbling around in the dark.
When you know how I'm being an idiot, you could fix things in github.com/dmcg/ktor-document... and let me know!
If you like this, you’ll probably like my book Java to Kotlin, A Refactoring Guidebook (java-to-kotlin.dev). It's about far more than just the syntax differences between the languages - it shows how to upgrade your thinking to a more functional style. - Наука та технологія
A resolution of sorts from @FranckRasolo
"The problem is that:
1. codeSnippets/build.gradle declares an explicit dependency on org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version
2. and in gradle.properties, kotlin_version is pointing to 1.9.10 instead of 1.9.24 (the latest)
Try making that change and you should be able to run ThroughputTests now."
So there is the version of Kotlin that Gradle is using to parse the build script (1.9.22), and version used to build Kotlin src in the project (1.9.10).
And then the version used to run the tests (1.9.23)
I was aware that the Kotlin version for running the gradle scripts vs the one for source code is usually different, but never knew that the version you run tests on can be different too! Good to know
I don’t think it’s quite that. It’s that the Gradle Kotlin plug used to build the Kotlin has its own Kotlin version, which is separate from the version parsing the scripts, and separate from the version of the the Kotlin compiler used to compile my code? I think
As an android dev... I just couldn't help laughing this entire video... cause yes
I'm glad we can share a laugh through the pain
@@RefactoringDuncan so the biggest trick is to understand that the JVM the IDE uses and what gradle uses (if you have system level gradle installed vs what Android Studio uses which is a local version) have very little to do with each other, so you need to align everything. I haven't "quite" figured out a purely systematic way to do this with intellej/android studio, but that's actually a goal of mine.
Then, update all your dependencies to where they don't need gradle upgraded, then upgrade gradle then upgrade your dependencies... It is a bit of a pain, but sadly this still works better than many other dep. mang. systems I've used.
The only other thing to watch out for is the order of dep. declarations actually determines which version is included in your jar/apk. (I wish the default would be to only include the newest version)
I would suggest that in the Gradle setting of Intellij to set the Gradle JDK back to Project SDK. Then go to the Project settings and set the project level SDK to Java 21. Upgrade Kotlin to 1.9.24 in gradle. Also set the kotlin jvmToolchain to 21. Then do a Reload Projects in the Gradle Tool Window. Then compile and build. This works for me at least.
Thank you for investigating. I think just the upgrade from the specified but hidden 1.9.10 is enough, but yes, making the the project use JDK21 and then the modules use the project setting makes things sane.
But how is there so much variation and configuration in one build?
@@RefactoringDuncan Tbh I think in almost all cases the JVM running Gradle should be the Project SDK. Even if in a few cases (wonder what those would be) it should be different then it would be great if these settings were in one place not in 2 completely different parts of the IDE.
And the best would be if this was automatically configured when I import the gradle project. Hopefully we will get there eventually.
Gradle.. why do you need to remember me of my trauma
My apologies!
I suggest getting it running in the terminal first. Any changes in IntelliJ settings seem irrelevant because you don't use IntelliJ to run the tests, yet.
When I switched to Flutter, I took a hard hit on the language side. But since that day, I never had to invest time getting my code to compile and run. It's such a relieve
Certainly being able to have differing settings for IntelliJ and the command line doesn’t help
Just searched it up, Kotlin 1.9.20 is the first version to support JDK 21. I think your Kotlin version is set to 1.9.10 or something similar. Hopefully updating it will fix this?
From the build that I can run
println(Runtime.version())
println(KotlinVersion.CURRENT)
19.0.2+7-44
1.9.23
;-(
@@RefactoringDuncan that's the original project where everything was running fine right? It's weird that it's on JDK 19, didn't expect that.
Are both projects on GitHub per chance? I'd love to take a look around
It's here (github.com/dmcg/ktor-documentation/tree/main/codeSnippets/snippets/tutorial-http-api) (I updated the video description too). As checked in it doesn't build, if you remove jvmToolchain(21) in build.gradle.kts it (for me at least) builds and runs under JDK 19
My guess, and it's just a guess, is that maybe a very recent version of Kotlin started supporting 21? In the project that does work with 21, check your Kotlin version there, and perhaps update this project to the same version. I think that's the common thread across all your errors here
Oh that’s a point. I mean it’s an appalling error message if you’re right, but I’ll give it a go!
Just another Monday
It was Thursday for me, and I had plans that weren't this rant
@@RefactoringDuncan Rant Approved!
😂 Android Dev here
Don't worry, some of my best friends are Android devs
GRADLE IS A COMPLETE NIGHTMARE, AFTER 10 YEARS ON ANDROID IT HAS IMPROVED EXACTLY .01%
No UI to explain the dependency graph, just bumble around and hack at it and try to get lucky at some point... exhausting and pointless... Pathetic engineering.
@@ChrisAthanas don't you know about --scan? btw gradle team made it for maven too. gradle guys can maven better than maven guys do
Scan is a useful facility. I do wish it was integrated by IntelliJ in some way.
I've always throught that Gradle is the worst thing ever created by human beings (slight hyperbole). It's like the Java community looked around at how EVERY OTHER language handles dependencies & builds and thought "Nah, that's far too simple".
You may be going a little too far, but I do wonder why JVM build tools feel the need to be so damn flexible.
Yes, how can we take this nice simple concept and make a huge business and industry around it that requires a rube goldberg machine for each project... BRILLIANT BUSINESS PLAN GUYS!
maybe because managing dependencies isn't simple, especially when there are tons of libraries with fucked up metadata out there. and maven poms cannot express the metadata right at all
Interestingly I have fewer problems managing dependencies than the build lifecycle, except for the dependencies of the plugins.