You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Aleksandar Seovic (JIRA)" <ji...@apache.org> on 2017/10/01 04:27:00 UTC

[jira] [Created] (MSHADE-261) Shade plugin removes module_info.class from the main module

Aleksandar Seovic created MSHADE-261:
----------------------------------------

             Summary: 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 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.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)