You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Alexander Kriegisch (Jira)" <ji...@apache.org> on 2021/04/04 04:13:00 UTC

[jira] [Comment Edited] (MSHADE-252) shadeSourcesContent is broken when combined with partial relocation

    [ https://issues.apache.org/jira/browse/MSHADE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314393#comment-17314393 ] 

Alexander Kriegisch edited comment on MSHADE-252 at 4/4/21, 4:12 AM:
---------------------------------------------------------------------

[~dhalperi], your problem is unrelated to shading sources, you are having a problem with shading binaries and getting package names in Strings inside those binaries relocated correctly. At least you had the problem in Maven Shade 3.0.0 which you were using at the time. I cloned your repository and reproduced it, then upgraded to Shade 3.2.4 and it just worked, despite the fact that you are also weirdly relocating the whole {{org}} package into its own deep subpackage {{org.apache.demo.shading.repackaged.org}}, excluding package {{org.apache.demo}}. So your problem is solved by simply upgrading the plugin version. BTW, instead of
{code:xml}
<excludes>
  org.apache.demo.**
</excludes>
{code}
which I was surprised to see working, I would use an exclude subtag and a single asterisk instead of two, because this is what Maven Shade expects as a subpackage specifier. Two asterisks are used in path specifiers for in-/excluding files, not in relocation patterns. As soon as you start to also shade sources, this would throw off the search and replace patterns, which only scan for a single asterisk at the and of a package in-/excludes string. So this is what I recommend:
{code:xml}
<excludes>
  <exclude>org.apache.demo.*</exclude>
</excludes>
{code}
But because it is not the first time I have seen {{{{*.***}}}} instead of *{{.*}}* in package name excludes, I have just now included a more lenient approach of pattern matching into my PR, which would also solve the problem for your sample project if you would start creating source JARs + relocation + excludes there. I added it locally to my clone of your project and tested it successfully.


was (Author: kriegaex):
[~dhalperi], your problem is unrelated to shading sources, you are having a problem with shading binaries and getting package names in Strings inside those binaries relocated correctly. At least you had the problem in Maven Shade 3.0.0 which you were using at the time. I cloned your repository and reproduced it, then upgraded to Shade 3.2.4 and it just worked, despite the fact that you are also weirdly relocating the whole {{org}} package into its own deep subpackage {{org.apache.demo.shading.repackaged.org}}, excluding package {{org.apache.demo}}. So your problem is solved by simply upgrading the plugin version. BTW, instead of
{code:xml}
<excludes>
  org.apache.demo.**
</excludes>
{code}
which I was surprised to see working, I would use an exclude subtag and a single asterisk instead of two, because this is what Maven Shade expects as a subpackage specifier. Two asterisks are used in path specifiers for in-/excluding files, not in relocation patterns. As soon as you start to also shade sources, this would throw off the search and replace patterns, which only scan for a single asterisk at the and of a package in-/excludes string. So this is what I recommend:
{code:xml}
<excludes>
  <exclude>org.apache.demo.*</exclude>
</excludes>
{code}
But because it is not the first time I have seen {{.**}} instead of {{.*}} in package name excludes, I have just now included a more lenient approach of pattern matching into my PR, which would also solve the problem for your sample project if you would start creating source JARs + relocation + excludes there. I added it locally to my clone of your project and tested it successfully.

> shadeSourcesContent is broken when combined with partial relocation
> -------------------------------------------------------------------
>
>                 Key: MSHADE-252
>                 URL: https://issues.apache.org/jira/browse/MSHADE-252
>             Project: Maven Shade Plugin
>          Issue Type: Bug
>    Affects Versions: 2.4.3, 3.0.0
>            Reporter: Zhenyu Yang
>            Priority: Major
>              Labels: easyfix
>
> per description in https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#shadeSourcesContent, when set it to true, 
> "it will attempt to shade the contents of the java source files when creating the sources jar." However, it seems will blindly shade all the source files include those are excluded from relocation rules.
> This could be illustrated with a simple example:
> Assume there are two classes defined in two packages as below:
> {code:title=A.java}
> package com.fake.fooA;
> import com.fake.fooB;
> public Class A {}
> {code}
> {code:title=B.java}
> package com.fake.fooB;
> import com.fake.fooA;
> public class B {}
> {code}
> and the maven config looks like:
> {code:xml}
>      <plugin>
>         <groupId>org.apache.maven.plugins</groupId>
>         <artifactId>maven-shade-plugin</artifactId>
>         <version>2.4.3</version>
>         <executions>
>           <!-- Run shade goal on package phase -->
>           <execution>
>             <phase>package</phase>
>             <goals>
>               <goal>shade</goal>
>             </goals>
>             <configuration>
>               <shadedArtifactAttached>false</shadedArtifactAttached>
>               <createSourcesJar>true</createSourcesJar>
>               <shadeSourcesContent>true</shadeSourcesContent>
>               <relocations>
>                 <relocation>
>                   <pattern>com.fake</pattern>
>                   <shadedPattern>.com.fake.shaded</shadedPattern>
>                   <excludes>
>                     <exclude>com.fake.fooA.*</exclude>
>                   </excludes>
>                 </relocation>
>                </relocations> 
> {code}
> Then the shade plugin will modify the B's source file to be:
> {code}
> package com.fake.shaded.fooB;
> import com.fake.shaded.fooA;
> public class B {}
> {code}
> Notice that package A's path was also updated, which is wrong as it's not got relocated.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)