Any simple solution for creating a runnable (main class set in manifest) kotlin/jvm jar with gradle ...

# announcements

[Toby]

Any simple solution for creating a runnable (main class set in manifest) kotlin/jvm jar with gradle kotlin dsl? None of the provided templates (in IntelliJ or Gradle) are working.

[jbnizet]

Why not simply configure the manifest of the jar? Something like

tasks.jar {
  manifest.attributes(mapOf("Main-Class", "your.main.Klass"))
}

I haven’t tested this at all and haven’t checked this is the correct attribute name, but I guess this should do what you want.

[jbnizet]

Of course you’ll also have to add a classpath attribute to reference the jars your application depends on. Any reason for not using the standard application plugin?

[Toby]

Your solution does not work since mapOf requires a different type. When creating the Kotlin project via IntelliJ, the application plugins gets added but no gradle task can produce a runnable jar.

[Toby]

I fixed your solution by implementing a pair:

tasks.jar {
    manifest.attributes(mapOf(Pair("Main-Class", "MainKt")))
}

But now there's a NoClassDefFoundError in cause of kotlin.jvm.internal.Intrinsics and implementing the stdlib does not help.

[jbnizet]

Oh sorry. The idiomatic way of creating a Pair is to use `to`: `mapOf(“Main-Class” to “your.main.Klass”)
If the exception you get is when running this executable jar file, then it’s related to the message I posted above: “Of course you’ll also have to add a classpath attribute to reference the jars your application depends on.“. The Kotlin stdlib is such a jar. The application plugin doesn’t produce an executable jar, but it produces scripts for all platforms that run the application ( and which are more flexible than just running an executable jar).

[Toby]

Thanks but why do I get the error even if I implement the stdlib as dependency?

[Vampire]

Because you didn't add it to the class path when you try to run your jar.
Let me repeat the question, why don't you use the application plugin?

[Vampire]

You are right that no task produces a runnable jar, because that's not what it produces. It produces a distribution archive with your code, your dependencies and generated start scripts for Windows and *nix.

[Vampire]

This archive you can unpack on the target system and run the appropriate start script and everything works

[Toby]

The application plugin does not produce a runnable jar files which I can use on every JVM. Although, its implemented as plugin.

[Vampire]

You can use the result of the application plugin also on every JVM, I don't get your point.

[Vampire]

What would be the benefit of a runnable jar over a proper distribution?
Besides that you don't only want a runnable jar, you want a fat jar and those are imho very bad practice and an abuse of java functionality that can also very easily be done wrongly and break stuff with not providing any real benefit.

[Toby]

How does this distribution thing work?

[Vampire]

Which thing exactly?

[Vampire]

How you configure it? How you build it? How you run it? How it works internally? ...?

[Vampire]

https://docs.gradle.org/current/userguide/application_plugin.html

[Toby]

So I cannot create a simple jar which I can execute with java -jar on every jvm?

[Vampire]

Not with the application plugin.
It is designed to build a proper distribution of your code and your dependencies that you can run on every jvm.

If you want to build a runnable jar instead which I strongly recommend against as it only brings problems and no benefit,
you have multiple options. You can build a bad-practice fat jar, that repackages all dependencies in your jar and imho everyone doing this should get hit by a pillar.
You can build a better-practice fat jar using Spring Boot, but that has other implications.
You can build a runnable JAR that has your dependencies besides it and besides the Main-Class attribute also a Class-Path attribute that references the dependencies.
To ship this you probably again pack everything into an archive, so imho you have nothing won opposed to simply using the application plugin that does everything properly for you and it just works.

[rnett]

@Toby you might want to look at jpackage

[Vampire]

That would just build an installer, that is not what he asked about. Besides that imho it is a pretty big miss-design as it does not even allow cross-building of the installers.