Hi guys, I already have several modules that have no reference to android/ios. So really pure Kotlin modules, business logic etc. The idea is the following three following repo's: • core • android implementations • ios implementations So I don't want to use the expect, actual mechanism, but just the interface/implementation mechanism. How do I set something like this up?

you could do 3 separate repos, or 3 modules in the same repo

Yes, 3 repos is what I want. Which multiplatform module project setup do I need to chose in intellij idea for the Core repo? Core repo consists of multiple modules. In the android/ios default setup I get android/ios folders created what I not want. I want the core repo to be pure, not having any mention of any platform.

that sounds closest to what you want

Even if all your code is common, the core module still needs to declare what platforms it builds for. So those templates will generate source folders for the platforms but you can delete the ones you don't have any code in. But you'll still have them declared in gradle.

Allright thanks. I have two more questions: Question 1: Right now my Core modules have the `

apply plugin: 'java-library'
apply plugin: 'kotlin'

in there build.gradle. Will this be replaced now with

plugins {
    id 'org.jetbrains.kotlin.multiplatform' version '1.3.61'
}

? Question 2:

yes on 1. For 2, opinions vary. Long-term I think kts is the way to go and I use it for my own projects, but IDE support can be inconsistent. There should be a checkbox on the templates though to generate kts scripts if you want.

I didn't see a checkbox for generating kts scripts. Im using intellij idea 2019.3.3

Oh. It's in the gradle kotlin templates but not the kotlin ones

Kotlin DSL is much easier to work with

Thanks guys, you've been helpful. Assuming we have this 3 repo setup, how is building meant? Am I supposed to open the core repo in intellij idea and open the android repo in Android studio? How is building and running done.

that's up to you. either include it as an inline subproject, or publish it to Maven. it depends on your work flows and how you want to run module releases

If you go down the publish to Maven path, does that mean that, for example I am trying to fix a bug in Core, and in order to test if it works on Android, I have to first publish it to maven with a new release 1.0.x+1? Which makes the release track polluted for just some trial and error

that's correct

So that makes the publishing to Maven thing really not an option, since trial and error developing isn't possible with that. Publishing Core to maven is only meant for teams were the core repo and android repo are really separate islands I guess.

but for iOS, ultimately you need a framework file. and if have multiple MPPs, you'll need one umbrella framework

I understand

you can try, but it may not build the target if you delete it's source set

My source was this:

Russell Wolf

Even if all your code is common, the core module still needs to declare what platforms it builds for. So those templates will generate source folders for the platforms but you can delete the ones you don't have any code in. But you'll still have them declared in gradle.

give it a try

So should I put all those sourcesets into the single root build.gradle file, making the seperate module gradle's redundant?

no

The similarity between all modules is that they only have commonMain and commonTest sourcesets. The difference ofcourse is that each module will have different dependencies.

i suspect you will apply the KMP plugin at that level

What about the target declaration

i doubt it, you'll have to experiment i think

Ok

You can omit the root level gradle file if you want. I usually have a small one with common repositories and some other simple config declared in an

allprojects{}

block I don't think you can share target definitions there but try it if you're curious. One way you can share some of that logic is using

buildSrc

. For example I have a bunch of helper logic here in Multiplatform Settings so I can just call

standardConfiguration()

at the module level. https://github.com/russhwolf/multiplatform-settings/blob/master/buildSrc/src/main/kotlin/BuildHelpers.kt

Thanks, gradle was always a black box, magic place for me

Yeah you can't do everything from there. Plugins block has to be at the top.

But then it says

Plugin [id: 'com.android.library'] was not found in any of the following sources:

You need an

android

block with at least a

compileSdkVersion

for any module with one of the Android plugins applied. If you use

jvm

for the Android side you don't need it

if you are not using Android SDK APIs, then you don't need the android plugin

Ah ok I get it, because jvm() target also works seamlessly on Android side ofcourse, right?

correct

Hey @Kris Wong, you were saying that there two options to use a mpp repo with a standalone android repo. The Publish to maven way and the other way. How should my Android repo reference the mpp repo this other way?

will there be frequent or infrequent changes in the KMP module?

Hmm, not sure yet. What would the difference be in setup?

well, if it were frequent, then I would add it as a subproject

Frequent changes in the KMP module, as in constantly trial and error debugging?

it would work the same as any other subproject in gradle

But if I add it as a subproject to my android project, won't the files be duplicated? Or is there a way I can make my android project add the mpp project as a subproject, without affecting the on-disk structure?

i would use git submodules

Hmm, is it hard to use?

i don't understand your question

You were suggesting me to drop the artifact in the libs folder, when the mpp has infrequent changes. Why shouldn't this be applied when it has frequently changes?

you really want to be manually copying artifacts around on every change, and not know which version of the artifact is actually in your libs folder?

I get it

include

it in settings.gradle, and add it as a

project

dependency in whatever project consumes it

Thanks for the quick response Kris, you're really helpful. Given a module_a in the core folder, does that mean the android-repo settings.gradle.kts should look like the following?:

include(..other, ":module_a")

yes. you just need to tell it where to find each project, since they are not in the source root

@Kris Wong Ok, this is how my settings.gradle.kts looks now. It works I think. The only issue I get now is the following build error:

Caused by: org.gradle.plugin.management.internal.InvalidPluginRequestException: Plugin request for plugin already on the classpath must not include a version

you have multiple projects that are using the same gradle plugin. you need to resolve it in the settings file, and remove the version from the build file

Ok, just for clarification, If I change this:

plugins {
    kotlin("multiplatform") version "1.3.70"
}

to this:

plugins {
    kotlin("multiplatform")
}

will that make gradle automatically use the latest version of the kotlin multiplatform plugin?

no

Which version would be used then?

try it and find out

I did, now getting the following error:

Plugin [id: 'org.jetbrains.kotlin.multiplatform'] was not found in any of the following sources:

. Looks like omitting the plugin version number isn't an option?

are you resolving it in the settings file?

No I didn't, because frankly I don't know how to. I found this: Do you mean something like this?:

yes

Ok, interesting, thanks

i am going to assume app is including the version

It doesn't, you can see it here: https://github.com/touchlab/KaMPKit/tree/master/app/build.gradle.kts

I see

the project is using

buildSrc

, which is a nice concept, but adds slight complication

I get it