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.

I mean, Gradle is Gradle, whether you're using the Kotlin or the Groovy language.

Perhaps that's the root cause of the mess.

Try using CMake, then complain about about JVM/Kotlin build tool eco system 😉

Uhh 😅

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.

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.

Gradle is a different kind of tool than composer or npm. It's like using a CNC machine with only experience on 3d printers.

I wouldn't be surprised... but honestly it started with copy & pasting stuff from the readme, so...

Was this in a fresh app or in an existing project?

existing project, pretty small one - started it a week or two ago

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.

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.

The dependencies is usually top-level in the build.gradle.kts file

Apparently it's not the case with KMP - it only caused weird errors when I did it in the outer file

My guess is that adding the serializer() is the plugins job, and you might need to "build" first before that becomes available.

to me it feels to magical and not obvious what anything is doing

Like I said before, Gradle is a powerful tool. Rather than let it remain magical, I'd spend some time to learn about Gradle.

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.

I doubt everyone runs into these issues, otherwise the instructions would probably be different.

well it all becomes pointless when the next new tool comes out

Not really.

well I believe that's a bad example

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?

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

Did you use Gradle with Java?

I think maven in the beginning...not sure, this was 7 years ago

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.

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.

That's my advice, anyway.

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.

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.

right, thanks for the discussion anyway

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/

nice! 😮 that seems to solve many of the problems/questions I've had

Also https://blog.gradle.org/declarative-gradle

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.

yeah, I realised that later...but in the end why even have that toml thing in the first place?

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.

well that new feature seems like a hack for the original mistake of mixing up build logic with declaring dependencies..

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.

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):

{ 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.

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.

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. 😂

You're still comparing apples to oranges here. package/composer is not the same type of tool as gradle.

> 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.

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.

I think gradle is great. Just need better documentation and more examples. But is great

@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:

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.

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. 🙂