K.H.
K.H.

Reputation: 1462

Create fat jar from kotlin multiplatform project

I recently switched from old 1.2 multiplatform into 1.3. Difference is, there's one one build.gradle file per multiplatform module (I got 5 of them) so a lot less configuration. However I can't seem to be able to configure creating runnable fat jar with all dependencies from jvm platform. I used to use standard "application" plugin in my jvm project and jar task, but that does not work anymore. I found there's "jvmJar" task and I modified it (set Main-class), but created jar doesn't contain dependencies and crashes on ClassNotFoundException. How do I do it?

This is what I have now:

    jvm() {
        jvmJar {
            manifest {
                attributes 'Main-Class': 'eu.xx.Runner'
            }
            from { configurations.compile.collect { it.isDirectory() ? it : zipTree(it) } }
        }

    }

Upvotes: 9

Views: 5203

Answers (5)

funbiscuit
funbiscuit

Reputation: 322

Proposed answers didn't work for me, probably kotlin plugin API changed. I use following setup with kotlin 2.0 plugin:

build.gradle.kts:

import com.github.jengelman.gradle.plugins.shadow.tasks.ShadowJar
import org.jetbrains.kotlin.gradle.ExperimentalKotlinGradlePluginApi

plugins {
    alias(libs.plugins.kotlinMultiplatform)
    alias(libs.plugins.shadow)
}

group = "com.funbiscuit"
version = "1.0-SNAPSHOT"

repositories {
    mavenCentral()
}

kotlin {
    val javaMainClass = "MainKt"

    jvm {
        @OptIn(ExperimentalKotlinGradlePluginApi::class)
        mainRun {
            mainClass = javaMainClass
        }
        withJava()

        tasks.register<ShadowJar>("jvmShadowJar") { // create fat jar task
            val mainCompilation = compilations["main"]
            val jvmRuntimeConfiguration = mainCompilation
                .runtimeDependencyConfigurationName
                .let { project.configurations[it] }

            from(mainCompilation.output.allOutputs) // allOutputs == classes + resources
            configurations = listOf(jvmRuntimeConfiguration)
            archiveClassifier.set("fatjar")
            manifest.attributes("Main-Class" to javaMainClass)
        }
    }

    sourceSets {
        commonMain.dependencies {
        }

        jvmMain.dependencies {
        }
    }
}

gradle/libs.versions.toml:

[versions]
kotlin = "2.0.0"
shadow = "8.3.4"


[plugins]
kotlinMultiplatform = { id = "org.jetbrains.kotlin.multiplatform", version.ref = "kotlin" }
shadow = { id = "com.gradleup.shadow", version.ref = "shadow" }

src/commonMain/kotlin/Main.kt:

fun main() {
    println("Hello!")
}

Upvotes: 0

luca992
luca992

Reputation: 1593

Got it working with the multiplatform plugin in kotlin 1.3.61:

The following works for a main file in src/jvmMain/kotlin/com/example/Hello.kt

Hello.kt must also specify its package as package com.example

I configured my jvm target in this way:

kotlin {
    targets {
        jvm()

        configure([jvm])  {
            withJava()
            jvmJar {
                manifest {
                    attributes 'Main-Class': 'com.example.HelloKt'
                }
                from { configurations.runtimeClasspath.collect { it.isDirectory() ? it : zipTree(it) } }
            }
        }
    }
}

Upvotes: 2

gunslingor
gunslingor

Reputation: 1476

The only way to get gradle/multiplatform working appears to be endless trial and error; It's a nightmare, it's not being built as a "build" system so much as a "build system"; to put it another way, these two tools (together or in isolation) are a means of implementing only a single software development life cycle that the plugin maker intended, however, if you've engineered a desired software lifecycle and CI/CD system and now your trying to implement that engineering, it will be MUCH harder to do it with these tools than it would be to do it with scripts, code or maven. There are a number of reasons for this:

  • Massive changing in coding convention due to the plugin makers only exposing bar minimum configurability, probably only giving access to the things they need for their own personal project.
  • Very poor documentation updates; Kotlin, gradle and plugins are changing so rapidly I have begun to seriously question the usefulness of these tools.

Thus, at the time of writing this seems to be the correct syntax to use when using kotlin 1.3.72, multiplatform 1.3.72, ktor 1.3.2 and gradle 6.2.2 (using the kts format).

Note the fatJar seems to assemble correctly but won't run, it can't find the class, so I included the second runLocally task I've been using in the mean time.

This isn't a complete solution so I hate posting it on here, but from what I can tell... it is the most complete and up to date solution I can find documented anywhere.

//Import variables from gradle.properties
val environment: String by project
val kotlinVersion: String by project
val ktorVersion: String by project
val kotlinExposedVersion: String by project
val mySqlConnectorVersion: String by project
val logbackVersion: String by project
val romeToolsVersion: String by project
val klaxonVersion: String by project
val kotlinLoggingVersion: String by project
val skrapeItVersion: String by project
val jsoupVersion: String by project
val devWebApiServer: String by project
val devWebApiServerVersion: String by project

//Build File Configuration
plugins {
    java
    kotlin("multiplatform") version "1.3.72"
}

group = "com.app"
version = "1.0-SNAPSHOT"

repositories {
    mavenCentral()
    jcenter()
    jcenter {
        url = uri("https://kotlin.bintray.com/kotlin-js-wrappers")
    }
    maven {
        url = uri("https://jitpack.io")
    }
}

//Multiplatform Configuration
kotlin {
    jvm {
        compilations {
            val main = getByName("main")
            tasks {
                register<Jar>("buildFatJar") {
                    group = "application"
                    manifest {
                        attributes["Implementation-Title"] = "Gradle Jar File Example"
                        attributes["Implementation-Version"] = archiveVersion
                        attributes["Main-Class"] = "com.app.BackendAppKt"
                    }
                    archiveBaseName.set("${project.name}-fat")
                    from(main.output.classesDirs, main.compileDependencyFiles)
                    with(jar.get() as CopySpec)
                }
                register<JavaExec>("runLocally") {
                    group = "application"
                    setMain("com.app.BackendAppKt")
                    classpath = main.output.classesDirs
                    classpath += main.compileDependencyFiles
                }
            }
        }
    }
    js {
        browser { EXCLUDED FOR LENGTH }
    }
    sourceSets { EXCLUDED FOR LENGTH }
}

Upvotes: 2

Julian Schubert
Julian Schubert

Reputation: 127

Got it to work with a slightly modified version of what luca992 did:

kotlin {
jvm() {
    withJava()
    jvmJar {
        manifest {
            attributes 'Main-Class': 'sample.MainKt'
        }
        from { configurations.runtimeClasspath.collect { it.isDirectory() ? it : zipTree(it) } }
    }
}
...
}

Upvotes: 1

andylamax
andylamax

Reputation: 2073

I did hit that bump and used this work around.

1. Restructure your project

Lets call your project Project.

create another submodule say subA, which will have the gradle notation Project:subA

now, subA has your multiplatform code in it (It is the gradle project with apply :kotlin-multiplafrom) in its build.gradle

2. Add Another submodule

create another submodule which targets only jvm say subB, which will have the gradle notation Project:subB

So, subB will have plugins: 'application' and 'org.jetbrains.kotlin.jvm'

3. Add your module as a gradle dependency (see my build.gradle)

plugins {
    id 'org.jetbrains.kotlin.jvm' version '1.3.31'
    id "application"
}

apply plugin: "kotlinx-serialization"

group 'tz.or.self'
version '0.0.0'

mainClassName = "com.example.MainKt"

sourceCompatibility = 1.8

compileKotlin {
    kotlinOptions.jvmTarget = "1.8"
}

dependencies {
    implementation project(':subA')
}

you can proceed and build subB as you would a regular java project or even use the existing plugins, it will work

Upvotes: 3

Related Questions