Thread
#multiplatform
    deviant

    deviant

    1 year ago
    hey guys, is it normal for kmm project? each time i change 1 line of code and try to rebuild - it's starting the cold build process with redownloading all dependencies etc. sometimes it takes like 40 mins. is it kmm plugin bug or android studio? can't find matching issue in the bug tracker
    Landry Norris

    Landry Norris

    1 year ago
    One of my co-workers had a similar issue. He set up the build folder on a RAM drive, and said the time went down from 1 hour to 20 minutes.
    deviant

    deviant

    1 year ago
    sounds promising 😄
    louiscad

    louiscad

    1 year ago
    Kotlin 1.5.21?
    c

    CLOVIS

    1 year ago
    I'm using multiplatform with JVM, JS and Android and never had anything like that. Do you have any more details on what exactly happens?
    Landry Norris

    Landry Norris

    1 year ago
    It's compiling it as several "separate" projects, so that may have an effect on speed. It seems very storage speed bound.
    Matthias Geisler

    Matthias Geisler

    1 year ago
    Sounds like you are doing something with Native...Actually the linker takes freaky long time to do his job...however somebody noticed that BuildCaches helps...but I did not had the time to try it myself...
    Mayank

    Mayank

    1 year ago
    Try Gradle offline mode. It should reduce the time.
    deviant

    deviant

    1 year ago
    yeah, offline mode helps. but why? looks like a bug for me. tried 1.5.10, 1.5.21. no defference. my project for now is just almost hello world kmm (android+ios) and jetpack compose
    c

    CLOVIS

    1 year ago
    We can't know why it does that without more info. What exactly is your config?
    deviant

    deviant

    1 year ago
    sure. we started our project following the oficial guide. created new kmm project in latest AS canary. added few libs like coroutines, moko, jetpack compose. we use gradle kotlin dsl for all scripts (may it be the root of all problems?). for now we are playing with android app only.
    c

    CLOVIS

    1 year ago
    Do you have the same problem with the hello world/template project?
    deviant

    deviant

    1 year ago
    i don't think so. but i already guess it should be fine since i'm the only person here who get this issue 🙂 let me check
    Mayank

    Mayank

    1 year ago
    My team was facing this exact issue. Gradle sync was fast in offline mode but too slow otherwise. We couldn’t find a solution until one day CI started failing. We found that dependency was getting resolved from wrong repository. And then it clicked that this could also be the reason for slow sync. We removed some unused repositories and rearranged them. It resolved the issue. I don’t know why gradle was downloading dependencies on every sync and couldn’t find anything on the net. But am content that its atleast fast now
    deviant

    deviant

    1 year ago
    @Mayank could you elaborate what exactly was the dependency/repo?
    Mayank

    Mayank

    1 year ago
    The root gradle buildscript repositories. We reordered them to
    buildscript {
        repositories {
            mavenLocal()
            gradlePluginPortal()
            google()
            mavenCentral()
             maven { url = uri("<https://dl.bintray.com/some_other_repo>") }
        }
    }
    Moving bintray repo to the bottom made a huge impact
    louiscad

    louiscad

    1 year ago
    You can just remove it, bintray repos are all offline now, killed by the sunset. Only jcenter is still around, read-only.
    deviant

    deviant

    1 year ago
    i have a progress on this 🙂 shuffled the repositories section a bit, and now crazy infinite dependencies donwloading gone. but now i stuck on the
    Build model...
    and
    Download maven-metadata.xml
    . 21 min so far...
    louiscad

    louiscad

    1 year ago
    Downloading such a file should take about 2 seconds on a 2G connection (Edge), and less than a second over other connections.
    deviant

    deviant

    1 year ago
    i know man 🙂 but my colleague has same issue in a totally different environment (same project). i'll try to investigate verbosed logs. unfortunately can't spend much time on this (not our main project, rather an early stage investigations)
    eventually figured out. you guys were right, it was a nasty bintray repo 🤦 now builds like a hurricane! case closed