What’s your suggested solution? Make MPP part of the Kotlin? That means Kotlin SDK, instead of being just a small tool, depends entirely on JVM, Android, iOS, some web technologies, and tens of bigger or smaller utilities - which is a huge mess. Develop a standalone build system for MPP? Spend months, even years on reinventing the wheel, duplicate existing utilities, partition the industry, require developers to learn this new build system and force them to switch between one and another depending on the use scenario. Or maybe create MPP as a plugin to the most commonly used and commonly known build system for JVM languages, which is also already the default / the only officially supported build system for building Android apps?
I wonder if you ever worked with any multiplatform technology which allows to run the code in both internet browser and iOS device and if your experience was much smoother than with MPP. Even crosscompiling to iOS itself is a pain, but yeah, let’s blame Gradle for everything just because it is a “running platform” for 50 utilities used underneath when crosscompilling to X entirely different runtimes.
It doesn’t matter what backend it uses. E.g., JS is a terrible language, but that doesn’t make Kotlin JS bad. And I’m pretty sure they will switch to a native implementation once the project gets traction.
MPP is the killer feature of the whole Kotlin ecosystem. It is responsible for 90% of Kotlin popularity. Which means there should be maximally independent and well described set of tools and processes to produce and work with artifacts.
The problem probably comes from the fact that JB is a tool producer. They sell products for developers to work with other technologies, and they adapt to technologies, which exist on market, they not invent them themselves. This is probably why they embedded gradle so deep inside their products, but in my opinion that was a strategic mistake.
When JB started their Kotlin project it was their claim to become technology company. If so, they should be ready and willing to invest in their own ecosystem, which works smoothly and reliably by its own.
And imagine we started this discussion by blaming JetBrains for locking developers into their products. Now we suggest they should develop a whole custom ecosystem, separate of existing industry standards
I guess this is a matter of taste. I hate when companies do this. I expect them to at least try to re-use or integrate with the industry standards. And make revolutionary changes only if really needed.
One thing I don’t understand is why you assume if they didn’t go for Gradle, then it would be any different. I doubt the root problem is in the Gradle, but in the multiplatform complexity and in the number of moving parts that are entirely out of control by JetBrains (Android, iOS).
Well, obviously there are “end points” that are and will always be out of control of JB - java, android, JS, iOS, native and and so on. Dealing with those end points is not avoidable, but a build tool is not such a thing!
In my opinion, a well designed build ecosystem would use conception of small independent tools producing their artifacts, stored in repositories, which may be used by other tools down the stream. Then those artifacts may be stashed in repository of choice (maven repository layout seems to be perfectly fine), but this repository may be isolated as well via ‘a driver’.
But this simple pattern is not used in Kotling MPP tooling, or otherwise there would not be PROJ_BASE_DIR.gradle\kotlin\kotlinTransformedMetadataLibraries folder with local copy of artifacts! Why each project using a library should have some local library artifacts inside it?
I am not sure if it is a flaw of gradle per say or a kotlin gradle plugin, but all of this is quite sad
That’s pretty much how Gradle works, except pushing all intermediary artifacts somewhere. Well, if using build cache I believe it actually works as you described it. Also, plugins and your project config control what is considered a final artifact that is uploaded somewhere and what is an intermediary artifact stored only locally.
(Now I started wondering if there is any other commonly used build system for any language that does something similar. Because this is a very sophisticated feature and I definitely don’t expect it in most build systems. It would be funny if it turns out Gradle is the only “well designed build ecosystem” according to your terms )
It’s quite the opposite. Gradle supports this, while I suspect almost no other build systems do. This is just too much sophisticated feature for most build systems.
We can even setup an HTTP server for storing intermediary artifacts and this means, if you compile test.kt file, then your colleague in your team doesn’t have to do it anymore (more or less).
Yeah this is exactly what I was saying, which I think maybe I wasn’t clear enough about. It seemed to me like OP’s complaints were mostly about Gradle, and Gradle != Kotlin. You can write Kotlin without Gradle, just like you can write Java without Gradle. My side note was that I don’t think there’s as much documentation or support for running the Kotlin compiler on its own, compared to documentation and support for running the Java compiler on its own.
Also yes, Gradle can be extremely frustrating, but unfortunately Jetbrains seem to only be supporting it, and not Maven. As far as I know (and I may be wrong), you can’t use Maven for Jetpack Compose or Kotlin Native. Jetpack Compose is apparently made by Google, so maybe they made the Gradle plugin and don’t want to make a Maven plugin. But Kotlin Native is made entirely by Jetbrains AFAIK, so they could make a Maven plugin.
EDIT: I originally said you can’t use Maven for Kotlin Multiplatform. This is also true, and it’d be nice if that was an option, but it’s less valuable since AFAIK you can’t use Maven with Android projects, so it makes sense to make the Multiplatform plugin only for Gradle.
You got any kind of evidence for this claim? Kotlin has a lot of good things, and Multiplatform support is pretty strong, but I highly doubt it’s responsible for 90% of Kotlin’s popularity. Maybe I’m just in my own bubble, but I think a lot of people like Kotlin for being a “better Java” but with really good Java interop, so you can use a much nicer language while still using all the Java libraries you’re familiar with.
I feel that an attempt to put it to Maven wouldn’t bring anything good. It would be the same problems + maven problems such as lack of support of complex features (like build cache), very rigid config and so on
I understand you pain with Gradle. But I feel that part of it just comes from complex use cases like Android or MPP, none of which even supported by Maven. I think instead of looking for some non existing magical solution, it’s better to embrace what we have and report bugs and let Kotlin team to improve it.
The problem with that is that Gradle is SO complicated that I’m never certain if it’s a bug with a Kotlin plugin, a bug with Gradle, or far more likely, a mistake in how I’ve done something because of the complex nature of Gradle and the severe lack of comprehensive documentation.
But yes, I can’t say that Maven will be better… I think the majority of my positive experience with Maven comes from the fact that I’ve just copied existing templates, and only really used it for managing dependencies. So maybe all build tools suck and are too complicated.
The problem with that is that Gradle is SO complicated that I’m never certain if it’s a bug with a Kotlin plugin, a bug with Gradle, or far more likely, a mistake in how I’ve done something because of the complex nature of Gradle and the severe lack of comprehensive documentation.
Right, but a big part of it is not the gradle itself but just the complex nature of the MPP setup. I do not want to make say that Gradle is famous for clear error messages, but often it’s not only about it. There is a massive set of tools involved in MPP build.
I also would say, that KMP plugin didn’t help, big part of complexity came from it and now Kotlin team is actually works to improve it, was very far from user friendly and quite custom (comparing to usual gradle plugin)
Oh I’m not even talking about KMP/MPP, I haven’t used that at all. Just basic Gradle usage, lol. Even something as simple as adding dependencies, or specifying which JDK to use, or excluding transitive dependencies… I feel like Gradle makes everything over complicated.
In my experience maven is slightly better documented. Also most gradle documentation seems to involve groovy DSL and I’m never quite certain how to translate that into kotlin. Other than that I don’t share any of these complaints personally.
Yeah I’m with gildor, pretty much every Gradle documentation I’ve read has provided Groovy syntax and Kotlin syntax. And tbh, they’re similar enough that I don’t think it’s too hard to translate.
)
It seemed to me like OP’s complaints were mostly about Gradle, and Gradle != Kotlin. You can write Kotlin without Gradle, just like you can write Java without Gradle. My side note was that I don’t think there’s as much documentation or support for running the Kotlin compiler on its own, compared to documentation and support for running the Java compiler on its own.