Should the gradle kotlin native plugin still be us...

# gradle

[wakingrufus]

Should the gradle kotlin native plugin still be used for native only projects, or should everything be MPP?

[gildor]

I think that choice is up to you, I belive that in any case we will have platform-specific plugins and MPP will not be the only option, so if you think that your project will be K/N only nothing wrong to use platform plugin

But there is one thing, I’m not really sure about K/N plans, but recently Kotlin JS got a new platform plugin which uses similar to MPP plugin DSL, so probably the same will happen with K/N and existing platform plugin will be deprecated, but it just my guess, I don’t know real plans

[wakingrufus]

Hmm OK thanks. This is in a project where some sub-projects are MPP for common code, and some are JVM or native only for specific apps, but I didnt want them all in the same MPP, because the plan is to distribute the shared code as libraries, and doing all the javafx stuff in a MPP script semms daunting. Maybe ill just do MPP for the k/n subprojects just so its only 1 thing to know

[gildor]

Yes, I think it’s just fine

[wakingrufus]

Cool. Thanks again

[r4zzz4k]

I'm not really sure about that.
https://kotlinlang.slack.com/archives/C3PQML5NU/p1552383109199000?thread_ts=1552298291.193200&cid=C3PQML5NU

[gildor]

But we talking not about kotlin-platform-common which is deprecated plugin for MPP development, but about platform-specific plugins

[gildor]

So to develop K/N project you can use
https://plugins.gradle.org/plugin/org.jetbrains.kotlin.native (K/N only)
or
https://plugins.gradle.org/plugin/org.jetbrains.kotlin.multiplatform (MPP, including K/N)

[gildor]

There is also deprecated konan plugin, but it replaced with org.jetbrains.kotlin.native

[r4zzz4k]

Sure, but they are part of the same infrastructure.
@Alexey Belkov [JB], could you please clarify the (future) status of platform plugins?

[gildor]

What do you mean “the same infrastructure”?

[gildor]

We have platform-specific plugin for each platform, JVM, Android, JS, Native. Some of them has 2 versions, but it’s just evolution process, they still a Gradle plugin for platform-specific development with Kotlin and old versions will be deprecated

And one MPP plugin that supports all of them in a single project

[r4zzz4k]

Well, yeah, you're most probably right.

[r4zzz4k]

I thought about expectedBy which binds them with -common, but this is the only user-facing thing probably.

[gildor]

Isn’t expectedBy is just feature of old deprecated kotlin-platform-* plugins for MPP? New MPP doesn’t need it

[gildor]

I now see what you mean, when I said “platform-specific” I didn’t mean old kotlin-platform-* plugins for multiplatform, I meant standalone plugins

[r4zzz4k]

That what I was thinking, that all these plugins have it, this they are obsolete. I've misthought kotlin-platform-native and org.jetbrains.kotlin.native. I mean, there is still a possibility they are the same thing under the hood, but that's not essential.

[ilya.matveev]

The kotlin-platform-native plugin isn't abandoned yet. But despite of that it's recommended to use the kotlin-multiplatform plugin, because it has better IDE support and is under active development now.

Another thought here is that Kotlin/Native projects are usually multiplatform by their nature. E.g. if we have a desktop K/N application, it will be built for 3 platforms: mac, linux and windows. So it's reasonable to use mechanisms provided by kotlin-multiplatform in such projects.

I've misthought kotlin-platform-native and org.jetbrains.kotlin.native. I mean, there is still a possibility they are the same thing under the hood

Yes, both these plugins use the same infrastructure under the hood. The only difference between them is that kotlin-platform-native in integrated with the old MPP model (== can have an expectBy dependency).

[r4zzz4k]

Thanks for clarifications!

[napperley]

One reason to use MPP over the Kotlin Native platform plugin is official Gradle Kotlin DSL support, unless the Konan plugin (marked as deprecated) is used instead.