mvysny / vaadin-on-kotlin

Writing full-stack statically-typed web apps on JVM at its simplest
https://www.vaadinonkotlin.eu/
MIT License
186 stars 17 forks source link

Question: Working Hot Reload Setup? #98

Open ecnaidar opened 1 year ago

ecnaidar commented 1 year ago

Hey, first of all, thank you for your work on bringing Vaadin to Kotlin! Especially amazing to see brewity Karibu DSL brings to creating views and reusable components ❤️

With that said, do you know if it is possible to get hotreload setup working with Kotlin and Karibu? (or perhaps some misconfiguration that causes the issue for me?)

We have a project based on VoK helloworld app and I could not get hotreload working on IntelliJ Community in a reasonable way with any of proposed solutions either from your Vaadin Boot or Vaadin docs so I would appreciate any comments or pointers if such setup exists.

again, dependency-wise it is forked from VoK helloworld app and while I updated some of dependencies and added others, it should not affect but posting gradle.kts here just in case it could give any information

Thank you for your time and any suggestions are welcome.

plugins {
    kotlin("jvm") version "1.8.0"
    id("com.vaadin") version "24.1.11"
    application
    id("com.avast.gradle.docker-compose") version "0.16.2"
}

defaultTasks("clean", "build")

repositories {
    mavenCentral()
}

dependencies {
    val VAADIN_VERSION = "24.1.11"
    val VOK_VERSION = "0.16.0"
    // Vaadin
    implementation("eu.vaadinonkotlin:vok-framework-vokdb:${VOK_VERSION}")
    implementation("com.vaadin:vaadin-core:${VAADIN_VERSION}") {
        afterEvaluate {
            if (vaadin.productionMode) {
                exclude(module = "vaadin-dev")
            }
        }
    }
    implementation("com.github.mvysny.vaadin-boot:vaadin-boot:12.0")
    implementation("com.github.mvysny.vaadin-simple-security:vaadin-simple-security:0.2")
    implementation("com.github.mvysny.vokorm:vok-orm:2.0")
    // REST
    implementation("eu.vaadinonkotlin:vok-rest:${VOK_VERSION}")

    // logging
    // currently we are logging through the SLF4J API to SLF4J-Simple. See src/main/resources/simplelogger.properties file for the logger configuration
    implementation("org.slf4j:slf4j-simple:2.0.6")

    // db
    implementation("com.zaxxer:HikariCP:5.0.1")
    implementation("org.flywaydb:flyway-core:9.15.2")
    implementation("org.postgresql:postgresql:42.6.0")

    // ldap
    implementation("com.unboundid:unboundid-ldapsdk:6.0.9")

    // Kotlin
    implementation(kotlin("stdlib-jdk8"))

    implementation("org.springframework.boot:spring-boot-devtools:3.0.6")
}

java {
    sourceCompatibility = JavaVersion.VERSION_17
    targetCompatibility = JavaVersion.VERSION_17
}

tasks.withType<KotlinCompile> {
    kotlinOptions.jvmTarget = "17"
}

tasks.withType<Test> {
    useJUnitPlatform()
    testLogging {
        // to see the exception stacktraces of failed tests in CI
        exceptionFormat = TestExceptionFormat.FULL
    }
}
mvysny commented 1 year ago

Thank you so much, I'm really happy that you like Vaadin-on-Kotlin :)

Unfortunately I have found no good solution for the hot-redeployment. I think it's connected to the massive number of closures/anonymous classes outputted for every dsl{} block; the classes change every time the hierarchy is changed. It's just a hunch, I have no proof or anything.

I also ended up using the JBR with all of the flags as mentioned with https://github.com/mvysny/vaadin-boot#advanced-hotswapping , but I'm mostly ending up with having to restart the JVM unfortunately. The JRebel pricing is too steep, and I'm not sure whether the hot-redeployment is actually better or not.

I wonder whether JBR 21 will have improved hot-redeployment... Maybe we can try to build JBR21 from https://github.com/JetBrains/JetBrainsRuntime/tree/jbr21 and try it out.

Let's keep this question open, maybe others have found a better solution.

ecnaidar commented 1 year ago

mostly ending up with having to restart the JVM

Yeah, sounds like a familliar sitation. Seems to work just fine when you only touch non-DSL classes or changing configs inside of existing DSL structures. Not sure if it depends on the depths, I will keep an eye out for it.

Thanks for the fast response on this anyway and let's see if situation improves in the future 👍