https://kotlinlang.org
Join Slack
Been fighting a bit with this: <https://github.com/Kotlin/kotlinx.serialization/issues/2509> That g...
# gradle
c
Been fighting a bit with this: https://github.com/Kotlin/kotlinx.serialization/issues/2509 That got me thinking.. "Kotlin [in principle] is a programming language that makes coding concise, cross-platform, and fun." So why on earth does it still depend on gradle and extend that mess? I imagine creating a new kind of package manager is a trivial matter compared to, say, creating the kotlin compiler(s). The switching from groovy to kts seems to be mainly for syntactical reasons - in the end it is still as complex.
d
I mean, Gradle is Gradle, whether you're using the Kotlin or the Groovy language.
👍 1
Also, for what its worth, Gradle is more than a "Package Manager".
And finally, Kotlin does not require Gradle. If you don't like Gradle, use something else. Maven works.
c
Perhaps that's the root cause of the mess.
d
Try using CMake, then complain about about JVM/Kotlin build tool eco system 😉
☝️ 3
💯 1
c
Uhh 😅
d
Sarcasm aside, I don't have an answer to you questions. Gradle is a pretty powerful (read: complex) tool. Even years of experience, I'm still learning new things about it.
FWIW, reading through that README.md, it looks somewhat straight forward.
c
Coming from a web environment, it's much easier to work with composer or npm for package management. In kotlin, I always get a feeling of dread each time I need to add a package. Just today for the link above, I faced 4 distinct errors that I haven't seen before. Of course I looked them up on the internets, but it didn't help much.
d
Gradle is a different kind of tool than composer or npm. It's like using a CNC machine with only experience on 3d printers.
Without seeing what you attempted, I can only guess what the actual problem was, but its possible you were making things more complicated than they needed to be, and it didn't work.
c
I wouldn't be surprised... but honestly it started with copy & pasting stuff from the readme, so...
d
Was this in a fresh app or in an existing project?
c
existing project, pretty small one - started it a week or two ago
d
Often times, older projects set up by other people have a lot of weirdness in them. I've seen some pretty gnarly gradle configurations at the company I work at.
c
For example, at one point everything seemed fine except it wouldn't build (said something about duplicate classes). Then I figured that the dependency line shouldn't be both in android and common sections, just the common one.
d
The dependencies is usually top-level in the build.gradle.kts file
same with plugins
FWIW, most of my experience is with server-side kotlin, so I don't know much about settings up an Android or KMP project.
c
Apparently it's not the case with KMP - it only caused weird errors when I did it in the outer file
At another point, 
@Serialization
annotation would be resolved/highlighted properly (from IDE, at least), but 
mySerializableClass.serializer()
wouldn't be.
d
My guess is that adding the serializer() is the plugins job, and you might need to "build" first before that becomes available.
There might be in IDE plugin to support it more directly.
c
to me it feels to magical and not obvious what anything is doing
that's also one of the arguments in the linked ticket, like why would you need a plugin for a serialization library
d
Like I said before, Gradle is a powerful tool. Rather than let it remain magical, I'd spend some time to learn about Gradle.
It's complex enough that just winging it will lead to this kind of (understandable) frustration.
c
But is it a good use of time? I'm not implying my time is particularly precious, but if everyone installing some dependency gets into these problems and needs to spend time learning gradle internals, I don't think is the way to go.
d
I doubt everyone runs into these issues, otherwise the instructions would probably be different.
If you're going to remain developing software, I do recommend spending time to learn your tools. All of the ones you use.
It is not only a good use of time, it is invaluable experience.
❤️ 1
It's also one of the traits that separates junior from senior engineers.
c
well it all becomes pointless when the next new tool comes out
d
Not really.
Imagine you buy a 3d printer. Are you going to just start using it without reading the instruction manual? Even if a newer model is coming out soon?
c
well I believe that's a bad example
d
Gradle is the tool you're using for this project. It is also not likely to be supplanted by anything else in the near future. Why not spend a couple of days reading about how it works?
c
a better example would be, using a specific 3d printer model for two years, switching to something else for 3 years, switching back to an upgrade of that printer for another 2 years, switching to something else for a year and then back to it
or in other words, I've worked with java for a bit more than two years and three years with kotlin
d
Did you use Gradle with Java?
c
I think maven in the beginning...not sure, this was 7 years ago
I get the general gist of gradle, but the problem with that is that it's a different problem every time.
and different configuration mind you
d
Either way, my point about the tool you're using now remains. You're struggling to get things working, and you said its because Gradle seems magical. Read the manuals, remove the magic, and struggle less.
c
It's also like you said a few moments ago - you're not sure because you're not using KMP. That doesn't look well on the tool.
d
That's my advice, anyway.
c
Yeah I get that, but I hope you also see the fact that no matter the amount of reading it won't help solve the frustration - if it's behaving differently on each scenario.
d
I disagree. If you have a better understanding of the tool itself, you'd have a better intuition on why it would behave certain ways in certain circumstances. In any case, I don't think there is much more to say on the topic. Good luck with your porjects.
c
right, thanks for the discussion anyway
👍 1
m
If gradle is too confusing, Amper might be something to look into: https://blog.jetbrains.com/blog/2023/11/09/amper-improving-the-build-tooling-user-experience/
👍 1
c
nice! 😮 that seems to solve many of the problems/questions I've had
v
h
Anyway, you "only" need to apply the Kotlin compiler plugin (as you did using 
alias
) and add the json library as dependency in commonMain. That's it. You can remove the other unrelated two entries in you libs.toml file.
c
yeah, I realised that later...but in the end why even have that toml thing in the first place?
As to amper and the blog post above, isn't it obvious that the problem is that gradle is used too much for unrelated things? Why mash up package management with task management? (and if that wasn't bad enough, make it too flexible so that every plugin can start using it for config management too)
h
It a new Gradle feature to configure your dependencies. Unlike npm/maven, which use a static json/xml file, Gradle uses code files for setup for dependencies and tasks. So you can declare your dependencies, tasks etc. using code, without any limits, with is a very powerful feature, especially for large/complex projects. Downside is the complexity, for newcomers as well as tooling. For dependency management tools, eg dependabot, the static toml file allows parsing and updating your dependencies without running your Gradle build.
c
well that new feature seems like a hack for the original mistake of mixing up build logic with declaring dependencies..
but thanks for the explanation
h
Well, it just depends on your use-case. I agree it should be easier for newcomers/small projects, somehow, but other use-cases require more complex build logic. And the Declarative Gradle project is the first step to reduce shooting yourself in the foot.
💯 1
c
I think the point that was missed in its design is that it should be flexible enough, but not too flexible. Either by splitting the various requirements (dependencies, config, tasks) into separate files, or by having a single file with a strict container structure (similar to many other package managers):
Copy code
{ devPackages: <..>, buildPackages: <..>, tasks: <..>, everythingElseHereIsInvalid }
In other words and following the arguments above, I could answer any question regarding Composer (php) not because I know every package possible, but because of convention and knowing the basics. In Gradle, this seems to depend on the package (plugin/dependency) in question and not just knowing gradle.
Anyway, thanks for all the info guys! I'll keep an eye out for amper.
h
The Kotlin Gradle plugin itself is one of the most complex Gradle plugins, due to the flexibility of Gradle ;) If you want to compare Gradle vs npm, use the built in Java plugin, this comparison will be fair. And you will notice, Gradle isn’t so complex, for simply applications. There is a dependencies block and the tasks block, which is enough for the most Java applications.
c
I was going to write a long retort to that, but here's a shorter one. 😄 Show a complex 
package.json
(or 
composer.json
) to a beginner, and they can tell you what it mostly means (and they'll be most probably right). Show them a simple 
gradle.build.kts
and they'll be wrong at best, and completely clueless at worse. I know, 'coz I just tried that on myself. 😂
d
You're still comparing apples to oranges here. package/composer is not the same type of tool as gradle.
v
> I know, 'coz I just tried that on myself. Then it probably was not a "simple" or even idiomatic one. Idiomatic Gradle build scripts are declarative. If the build script is too complex to understand, it is user error. With great power comes gread responsibility. If some users misuse the power and flexibility to write hard to understand builds, don't blame it on the tool. And if you blame it on the tool and it does not what you like, there are luckily some other tools to choose from like Maven, Bazel, Ant, Ant with Ivy, Make, ... Choose whatever tool matches your requirements and expectations best.
plus1 4
e
Tldr invest some time in learning Gradle; you'll definitely gain from it. I've been working with Gradle for 10 years now. I spent the first few years fighting it, with the mentality that it should just work without me putting anything into it. Then I decided I was getting nowhere with that approach. So I invested time in learning how it works, and why it works the way it does. Now I love gradle, and (no offense) have trouble understanding why people complain about it. Can it do better? Sure. Mainly there's a lot of conflicting legacy API, which gets confusing. Some things can definitely use some polish. I work at the intersection of AGP, KGP, and Compose so things don't always align, but Google, Jetbrains, and Gradle are getting better at collaborating on these things.
plus1 8
p
I think gradle is great. Just need better documentation and more examples. But is great
c
@Vampire
Then it probably was not a "simple" or even idiomatic one.
Idiomatic Gradle build scripts are declarative.
I checked the root build script for a KMP project, it looks like so:
Copy code
plugins {
    // this is necessary to avoid the plugins to be loaded multiple times
    // in each subproject's classloader
    alias(libs.plugins.jetbrainsCompose) apply false
    alias(libs.plugins.androidApplication) apply false
    alias(libs.plugins.kotlinMultiplatform) apply false
    id("com.louiscad.complete-kotlin") version "1.1.0"
}
So yeah, relatively simple script. However, assuming the reader already knows about plugins, there's still: • it's not obvious what the comment is directed it - what is "this" in that context? • why alias()? • why apply false? how is that idiomatic? • why id()? • PS: ctrl-clicking into any of that pulls up the decompiler (to be fair, auto-completion does show some good documentation) Anyway, I don't need answers to that, just wanted to point it out.
v
Well, actually any build that combines AGP, KMP, and Compose cannot be called "simple". 😄 Those are most probably the three most complex plugins in the ecosystem currently and combining them is not really fun. 😄. That "this" is not clear as I said is caused by the build author, not by Gradle. Having those 
apply false
lines is one option to mitigate the problem that is fixed by it, but it could also be done differently in a more read-friendly way. That 
ctrl+click
is not yet leading to the actual version catalog entry is just a missing feature in the IDE that is hopefully coming at some point in time. That some plugins are coming from version catalog and use 
alias
while one plugin is applied directly by ID instead of version catalog, again is due the build author writing it that way instead of having all in the version catalog. So yes, this build could of course be written differently to maybe be more beginner-read-friendly. 🙂
👍 3
6 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by