Toby
04/07/2021, 1:21 PMjbnizet
04/07/2021, 1:37 PMtasks.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
04/07/2021, 1:39 PMToby
04/07/2021, 1:40 PMToby
04/07/2021, 1:46 PMtasks.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
04/07/2021, 2:23 PMToby
04/07/2021, 2:42 PMVampire
04/07/2021, 3:32 PMapplication
plugin?Vampire
04/07/2021, 3:33 PMVampire
04/07/2021, 3:33 PMToby
04/07/2021, 4:09 PMVampire
04/07/2021, 4:10 PMapplication
plugin also on every JVM, I don't get your point.Vampire
04/07/2021, 4:13 PMToby
04/07/2021, 4:20 PMVampire
04/07/2021, 4:47 PMVampire
04/07/2021, 4:47 PMVampire
04/07/2021, 4:47 PMToby
04/07/2021, 4:57 PMjava -jar
on every jvm?Vampire
04/07/2021, 5:03 PMapplication
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
04/07/2021, 9:24 PMjpackage
Vampire
04/07/2021, 9:33 PM