Exclude manifest and module-info when creating an uber-jar #317
Conversation
| @@ -35,22 +35,14 @@ fun Project.createJvmBenchmarkCompileTask(target: JvmBenchmarkTarget, compileCla | |||
| dependsOn("${target.name}${BenchmarksPlugin.BENCHMARK_COMPILE_SUFFIX}") | |||
| archiveClassifier.set("JMH") | |||
| manifest.attributes["Main-Class"] = "org.openjdk.jmh.Main" | |||
|
|
|||
| exclude("META-INF/**/module-info.class", "META-INF/**/MANIFEST.MF") | |||
There was a problem hiding this comment.
This PR is set to close #314. However, these paths don't seem to cover the conflicts reported in the issue, namely LICENSE.txt files in dependencies and *.kotlin_module files. Perhaps I'm misunderstanding something but − as it stands − I don't see how this fixes the original problem.
There was a problem hiding this comment.
Yep, sorry, let me elaborate.
There are a few files that should be skipped when packing an uber-jar - neither module-info, nor manifests make sense for the resulting jar.
Currently, the plugin doesn't skip them effectively, and that could be fixed.
For other files, in general, it's not a good idea to exclude them from jar, and I don't think the plugin can make that choice for a user here. For example, .kotlin_module files removal may result in reflection-related issues in runtime.
If there are clashes between some files, there's a warning and you're sure that the best way to handle it is by excluding files from the resulting jar, then you can get a Jar task by its name (or its type) and add extra exclusion rules.
There was a problem hiding this comment.
Thanks for the explanation. From a user's PoV though, I think this problem is quite obscure. On non-JVM platforms that don't need an uber jar, I suspect you don't have to worry about this. But due to an internal implementation detail of kotlinx-benchmark on the JVM, the benchmark assembly process runs into a problem that potentially produces an invalid jar.
And it's not like the current status is any better than excluding all conflicting files: there's no way to tell which source jar will win out when there are conflicts, so it's probably a case of incorrect behaviour by default.
Closes #314