[
https://issues.apache.org/jira/browse/MSHADE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17911766#comment-17911766
]
Tatu Saloranta commented on MSHADE-261:
---------------------------------------
I wish I had found this issue sooner, before wasting hours trying to resolve
the same issue.
It looks like `module-info.class` is dropped if:
# "minimize" enabled (by `MinijarFilter`)
# ... but also, even if not, by `DefaultShader`
and apparently there is no way to opt out. I think it should be possible to
turn off this filtering given that it seems possible to produce working
`module-info.class` (esp. by using Moditect plug-in).
> Shade plugin removes module_info.class from the main module
> -----------------------------------------------------------
>
> Key: MSHADE-261
> URL: https://issues.apache.org/jira/browse/MSHADE-261
> Project: Maven Shade Plugin
> Issue Type: Bug
> Affects Versions: 3.1.0
> Environment: OS X, Java 9+181, Maven 3.5.0
> Reporter: Aleksandar Seovic
> Priority: Major
>
> I've noticed that {{maven-shade-plugin 3.1.0}} removes all
> {{module_info.class}} files from the shaded artifact. In my opinion, this is
> wrong.
> I understand why it makes sense to remove {{module_info}} from the
> dependencies that are included into the final artifact by the {{shade}}
> plugin, but it should not be removed from the main artifact dependencies are
> being shaded into.
> For example, I just had to repackage gRPC Java by creating a project that
> merges several gRPC artifacts ({{grpc-core}}, {{grpc-context}} and
> {{grpc-stub}}) into a single [{{io.grpc}} Java 9
> module|https://github.com/aseovic/io.grpc] in order to address the split
> package issue (both {{grpc-core}} and {{grpc-context}} have classes in the
> {{io.grpc}} package, which makes them unusable as Java 9 modules by default).
> In the process, I've run {{jdeps}} against the original JARs and have created
> a [proper Java 9 module
> descriptor|https://github.com/aseovic/io.grpc/blob/master/src/main/java/module-info.java]
> based on what the original JARs export and require, hoping to create a
> single JAR that can be used correctly as a Java 9 module, as a temporary
> workaround until the root issue of split packages is addressed by the gRPC
> team.
> However, I wasn't able to get {{shade}} plugin to include my
> {{module_info.class}} into the final artifact, no matter what I tried. In the
> end, I downgraded to version 3.0.0, which did what I wanted it to do and left
> my {{module_info}} alone.
> I can also foresee legitimate scenarios where I would want to shade and
> relocate some dependency (ASM, for example) inside my module, but that
> doesn't mean that my {{module_info}} should disappear. Nothing changes with
> regard to my module's encapsulation and requirements just because I've
> embedded ASM into it, other than the fact that the ASM is no longer an
> external dependency.
>
> To summarize, while I agree that merging of different module descriptors is
> not something Maven Shade Plugin should do, and that stripping of module
> descriptors from the artifacts included by the shade plugin probably makes
> most sense, I do believe that a hand-written module descriptor in the main
> artifact should be left alone.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
