Thread
#multiplatform
    Orhan Tozan

    Orhan Tozan

    2 years ago
    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?
    Kris Wong

    Kris Wong

    2 years ago
    you could do 3 separate repos, or 3 modules in the same repo
    Orhan Tozan

    Orhan Tozan

    2 years ago
    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.
    @Kris Wong
    Do I need to choose Multiplatform Library?
    Kris Wong

    Kris Wong

    2 years ago
    that sounds closest to what you want
    russhwolf

    russhwolf

    2 years ago
    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.
    Orhan Tozan

    Orhan Tozan

    2 years ago
    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:
    The generated gradles are in default groovy I see (build.gradle). Is it recommended to switch to the newer kotlin dsl gradle files? (build.gradle.kts) ?
    russhwolf

    russhwolf

    2 years ago
    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.
    Orhan Tozan

    Orhan Tozan

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

    russhwolf

    2 years ago
    Oh. It's in the gradle kotlin templates but not the kotlin ones
    There's also samples online you can look at, eg https://github.com/touchlab/KaMPKit
    Kris Wong

    Kris Wong

    2 years ago
    Kotlin DSL is much easier to work with
    Orhan Tozan

    Orhan Tozan

    2 years ago
    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.
    Should I publish the Core to maven and make the android repo just use it as a external dependency? How would the flow of that go, debuggin etc.
    Kris Wong

    Kris Wong

    2 years ago
    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
    Orhan Tozan

    Orhan Tozan

    2 years ago
    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
    Or am I missing somethign
    Kris Wong

    Kris Wong

    2 years ago
    that's correct
    it's also not too complicated to define a flag in a local properties file that will allow each developer to switch between inline project, and artifact repo (default)
    Orhan Tozan

    Orhan Tozan

    2 years ago
    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.
    Kris Wong

    Kris Wong

    2 years ago
    but for iOS, ultimately you need a framework file. and if have multiple MPPs, you'll need one umbrella framework
    i'd say that's correct
    it's really to everyone's benefit if you have a unit test for every use case in your MPP
    Orhan Tozan

    Orhan Tozan

    2 years ago
    I understand
    I should to delete all of those sourceSets except commonMain and commonTest, right?
    I see that every module has is own build.gradle with mpp and sourceset definitions. What is the use of the root build.gradle (yellow one)?
    Kris Wong

    Kris Wong

    2 years ago
    you can try, but it may not build the target if you delete it's source set
    it's for project level configuration
    Orhan Tozan

    Orhan Tozan

    2 years ago
    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.
    Previously in the thread
    Kris Wong

    Kris Wong

    2 years ago
    give it a try
    Orhan Tozan

    Orhan Tozan

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

    Kris Wong

    2 years ago
    no
    you should only put things in the root that apply to every module
    Orhan Tozan

    Orhan Tozan

    2 years ago
    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.
    So with this situation, I guess the root build.gradle doesn't have anything to add that it can apply for every module, making the root build.gradle redundant/useless? Is it better for me to delete the root build.gradle?
    Kris Wong

    Kris Wong

    2 years ago
    i suspect you will apply the KMP plugin at that level
    i actually haven't tried a multi-module setup for KMP
    Orhan Tozan

    Orhan Tozan

    2 years ago
    What about the target declaration
    Can I just declare this (everything in the red square) once in the root build.gradle, and not mention it again in the individual module build.gradle's ?
    Kris Wong

    Kris Wong

    2 years ago
    i doubt it, you'll have to experiment i think
    Orhan Tozan

    Orhan Tozan

    2 years ago
    Ok
    Can I just put this code in every module build.gradle, and delete the root build.gradle completely?
    russhwolf

    russhwolf

    2 years ago
    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
    Orhan Tozan

    Orhan Tozan

    2 years ago
    Thanks, gradle was always a black box, magic place for me
    But now I learn slowly how it actually works
    How do I specify plugins for every module in the root gradle?
    This doesn't work
    Gives me a build error
    russhwolf

    russhwolf

    2 years ago
    Yeah you can't do everything from there. Plugins block has to be at the top.
    Orhan Tozan

    Orhan Tozan

    2 years ago
    But then it says
    Plugin [id: 'com.android.library'] was not found in any of the following sources:
    Taken from the KampKit github sample @Kris Wong, I assume this is necessary for every module even tho it has no android code?
    Is it even required for my domain code module to specify the above?
    russhwolf

    russhwolf

    2 years ago
    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
    Kris Wong

    Kris Wong

    2 years ago
    if you are not using Android SDK APIs, then you don't need the android plugin
    change your target to JVM
    otherwise, you will need android config block, AndroidManifest.xml, etc...
    Orhan Tozan

    Orhan Tozan

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

    Kris Wong

    2 years ago
    correct
    Orhan Tozan

    Orhan Tozan

    2 years ago
    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?
    Kris Wong

    Kris Wong

    2 years ago
    will there be frequent or infrequent changes in the KMP module?
    Orhan Tozan

    Orhan Tozan

    2 years ago
    Hmm, not sure yet. What would the difference be in setup?
    Kris Wong

    Kris Wong

    2 years ago
    well, if it were frequent, then I would add it as a subproject
    otherwise I'd drop the artifact in libs
    Orhan Tozan

    Orhan Tozan

    2 years ago
    Frequent changes in the KMP module, as in constantly trial and error debugging?
    How do I add the kmp project as a subproject?
    And an artifact is something like a generated .jar of the project but then in kotlin mpp form?
    Kris Wong

    Kris Wong

    2 years ago
    it would work the same as any other subproject in gradle
    Orhan Tozan

    Orhan Tozan

    2 years ago
    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?
    Kris Wong

    Kris Wong

    2 years ago
    i would use git submodules
    Orhan Tozan

    Orhan Tozan

    2 years ago
    Hmm, is it hard to use?
    Also, why would the link the artifact of the mpp to android not work for frequent changes?
    Kris Wong

    Kris Wong

    2 years ago
    i don't understand your question
    Orhan Tozan

    Orhan Tozan

    2 years ago
    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?
    Kris Wong

    Kris Wong

    2 years ago
    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?
    Orhan Tozan

    Orhan Tozan

    2 years ago
    I get it
    So we are talking about the artifacts in the.idea/artifacts/ folder right?
    @Kris Wong I set up the git submodules in the android repo. It looks something like this now:
    android-repo/
        build.gradle
        settings.gradle.kts
        (..android-modules)
        core (git submodule) /
            (..mpp-modules)
            build.gradle
            settings.gradle.kts
    How should my android modules build.gradles reference the mpp modules as a dependency?
    Kris Wong

    Kris Wong

    2 years ago
    include
    it in settings.gradle, and add it as a
    project
    dependency in whatever project consumes it
    Orhan Tozan

    Orhan Tozan

    2 years ago
    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")
    Kris Wong

    Kris Wong

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

    Orhan Tozan

    2 years ago
    @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
    Kris Wong

    Kris Wong

    2 years ago
    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
    Orhan Tozan

    Orhan Tozan

    2 years ago
    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?
    Kris Wong

    Kris Wong

    2 years ago
    no
    Orhan Tozan

    Orhan Tozan

    2 years ago
    Which version would be used then?
    Kris Wong

    Kris Wong

    2 years ago
    try it and find out
    Orhan Tozan

    Orhan Tozan

    2 years ago
    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?
    Kris Wong

    Kris Wong

    2 years ago
    are you resolving it in the settings file?
    Orhan Tozan

    Orhan Tozan

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

    Kris Wong

    2 years ago
    yes
    Orhan Tozan

    Orhan Tozan

    2 years ago
    Ok, interesting, thanks
    Is there any reason why the KaMPKit github doesn't have this?
    Kris Wong

    Kris Wong

    2 years ago
    i am going to assume app is including the version
    Orhan Tozan

    Orhan Tozan

    2 years ago
    Orhan Tozan

    Orhan Tozan

    2 years ago
    I see
    Whats the difference between useModule and classpath?
    Kris Wong

    Kris Wong

    2 years ago
    the project is using
    buildSrc
    , which is a nice concept, but adds slight complication
    Orhan Tozan

    Orhan Tozan

    2 years ago
    I get it
    So I should just stick to the settings.gradle.kts example earlier in the conversation right
    I managed to make it work by resolving it in the root build.gradle.kts. Thanks for the help Kris!