Skip to content

Exclude manifest and module-info when creating an uber-jar - #317

Open
fzhinkin wants to merge 1 commit into
masterfrom
314-filter-module-info
Open

Exclude manifest and module-info when creating an uber-jar#317
fzhinkin wants to merge 1 commit into
masterfrom
314-filter-module-info

Conversation

@fzhinkin

Copy link
Copy Markdown
Collaborator

Closes #314

@fzhinkin
fzhinkin requested a review from shanshin June 19, 2025 20:20
archiveClassifier.set("JMH")
manifest.attributes["Main-Class"] = "org.openjdk.jmh.Main"

exclude("META-INF/**/module-info.class", "META-INF/**/MANIFEST.MF")

@viluon viluon Jun 19, 2025

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@fzhinkin fzhinkin Jun 19, 2025

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

JMH Jar generation runs into META-INF duplicates

3 participants