[
https://issues.apache.org/jira/browse/MSHADE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandar Seovic updated MSHADE-261:
-------------------------------------
Description:
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.
was:
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 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 modules 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 `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.
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 hand-written module descriptor in the main artifact
should be left alone.
> 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
>
> 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
(v6.4.14#64029)
