:wave: I just took some time to get compose hot re...

# compose-desktop

[Dmitriy Tarasevich]

👋 I just took some time to get compose hot reload into my 9-5 project since 2.1.20 enabled configuration caching to work with it, unfortunately it seems like within the past few versions a new task has been introduced that looks like syncdesktopMainApplicationClasses which takes roughly 1 minute to compile and spits out logs like the following

file '/Users/dmitriytarasevich/.gradle/caches/8.11/transforms/798854b096b6a05b98708be9554307cf/transformed/feature-streaming-pip-jvm-0.7.0/META-INF/MANIFEST.MF' will be copied to '/Users/dmitriytarasevich/dev/fbg-kmp-sdk-alternate/desktop/app/build/run/desktopMain/classes/META-INF/MANIFEST.MF', overwriting file '/Users/dmitriytarasevich/.gradle/caches/8.11/transforms/6431cd6a7bfda5fd687ab9108f3850f8/transformed/foobar-sdk-jvm-0.7.0/META-INF/MANIFEST.MF', which has already been copied there.

for each module we have in the project, seeing as we have around 100 modules this steps takes quite a bit of time.

Due to this issue, the inclusion of compose hot reload actually makes incremental builds substantially slower.

Please let me know if there is any additional information you need.

[Fudge]

@Sebastian Sellmair [JB]

[Sebastian Sellmair [JB]]

Thanks for marking me! I This report is rather important!
We'll work on supporting 'jar based' reloads which is expected to get rid of the overhead. I once had a prototype but I was missing good indicators how much this will help. Guess I will generate a 100 module app and test there

[Dmitriy Tarasevich]

can you elaborate on what you mean about jar based reloads? Is it the way my project is structured that is causing this?

[Dmitriy Tarasevich]

also in the future would you prefer to be tagged on issues related to hotswap?

[Sebastian Sellmair [JB]]

Yes of course:
Right now, the Gradle implementation of hot reload is launching your app directly on .class files in directories (not packaged in jars).
This is because JVMs reading and loading from .jars have issues when the jar changes during hot reload.
The plain .class files can be resolved very easily by the JVM, even when they change.
However, this means that all your compiled code gets synced into directories first, which can take too much time (see your 1 minute).
This means, it would be desirable to launch the JVM based upon jars and get rid of the syncing of all class files

[Sebastian Sellmair [JB]]

I expect this change to land in the next alpha

[Dmitriy Tarasevich]

Makes sense. Thanks for the explanation and all the work your putting into this project, my team is super excited to get this integrated

[Sebastian Sellmair [JB]]

Here is the 'Call for Feedback' dev build which includes the changes:
https://github.com/JetBrains/compose-hot-reload/releases/tag/v1.0.0-alpha06-106

I would be very happy to hear from you, if this would work

[Dmitriy Tarasevich]

wow, i was literally just thinking about when this would come out lol

[Dmitriy Tarasevich]

crazy timing, ill give it a go in the next couple hours

[Dmitriy Tarasevich]

got an error syncing

:desktop:app:desktopDev: Could not find org.jetbrains.compose.hot-reload:runtime-api:1.0.0-alpha06-106.

[Dmitriy Tarasevich]

@Sebastian Sellmair [JB] I see

The default 'runtime-api' dependency was removed. Wrapping code into DevelopmentEntryPoint {}

In the notes but it seems as though its still looking for it?

[Sebastian Sellmair [JB]]

Is the dev repository available in your project?

[Sebastian Sellmair [JB]]

dev compilations still see this dependency

[Dmitriy Tarasevich]

it is

[Dmitriy Tarasevich]

pluginManagement {
    repositories {
        gradlePluginPortal()
        mavenCentral()
        google()
        maven("<https://api.touchlab.dev/public>")
        maven("<https://packages.jetbrains.team/maven/p/firework/dev>")
    }
}

dependencyResolutionManagement {
    repositories {
        mavenCentral()
        maven("<https://api.touchlab.dev/public>")
        maven("<https://androidx.dev/storage/compose-compiler/repository/>")
        maven("<https://packages.jetbrains.team/maven/p/firework/dev>")
    }
}

[Sebastian Sellmair [JB]]

What could still happen is that a subproject is overwriting the repos.
You could guard against that using

dependencyResolutionManagement {
    repositoriesMode = RepositoriesMode.FAIL_ON_PROJECT_REPOS