maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksandar Seovic (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (MSHADE-261) Shade plugin removes module_info.class from the main module
Date Sun, 01 Oct 2017 04:33:00 GMT

     [ 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)

Mime
View raw message