Uploaded image for project: 'Maven Shade Plugin'
  1. Maven Shade Plugin
  2. MSHADE-240

support relocation pom.properties and pom.xml descriptors in shaded jars

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.4.3
    • Fix Version/s: 3.0.0
    • Labels:
      None

      Description

      When using shade plugin to embbed (and relocate to be safe) some dependency the final jar ends up with the dependency /META-INF/maven/<groupid>/<artifactid>/* files.

      The problem is that in the final jars those files essentially become a lie for any tools looking at those descriptors to find out what the jar contains and you end up with false positive.

      Ideally they should be stripped when relocating a dependency since it means the jar does not contain what is indicated in those files anymore, only something that happen to have the same feature but with completely different packages (so unusable). An alternative is to move them in some other place like /META-INF/shade/maven/<groupid>/<artifactid>/* for example, so that you still keep information about what has been shaded.

        Activity

        Hide
        tmortagne Thomas Mortagne added a comment -

        Note: I can try to implement it if I'm not the only one thinking it would be nice and with some pointers of where it would be the cleanest to do that (I was thinking about somewhere in DefaultShader#shadeJars)

        I would suggest skip those files if there is any relocation (i.e. the jar is missing stuff and can't be considered the same anymore) but keep them if nothing is modified (jar merged as it is).

        Show
        tmortagne Thomas Mortagne added a comment - Note: I can try to implement it if I'm not the only one thinking it would be nice and with some pointers of where it would be the cleanest to do that (I was thinking about somewhere in DefaultShader#shadeJars) I would suggest skip those files if there is any relocation (i.e. the jar is missing stuff and can't be considered the same anymore) but keep them if nothing is modified (jar merged as it is).
        Hide
        rfscholte Robert Scholte added a comment -

        I haven't activated it by default, but at least it is now a lot easier to achieve using the following relocator:

                        <relocation>
                          <pattern>META-INF/maven</pattern>
                          <shadedPattern>META-INF/shade/maven</shadedPattern>
                          <excludes>
                            <exclude>META-INF/maven/${project.groupId}/${project.artifactId}/pom.*</exclude>
                          </excludes>
                        </relocation>
        
        Show
        rfscholte Robert Scholte added a comment - I haven't activated it by default, but at least it is now a lot easier to achieve using the following relocator: <relocation> <pattern> META-INF/maven </pattern> <shadedPattern> META-INF/shade/maven </shadedPattern> <excludes> <exclude> META-INF/maven/${project.groupId}/${project.artifactId}/pom.* </exclude> </excludes> </relocation>
        Hide
        hudson Hudson added a comment -

        SUCCESS: Integrated in Jenkins build maven-plugins #8621 (See https://builds.apache.org/job/maven-plugins/8621/)
        MSHADE-240 support relocation pom.properties and pom.xml descriptors in shaded jars (rfscholte: http://svn.apache.org/viewvc/?view=rev&rev=1779644)

        • (add) maven-shade-plugin/src/it/MSHADE-240_reloc-mavenfiles
        • (add) maven-shade-plugin/src/it/MSHADE-240_reloc-mavenfiles/pom.xml
        • (add) maven-shade-plugin/src/it/MSHADE-240_reloc-mavenfiles/verify.groovy
        • (edit) maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/relocation/SimpleRelocator.java
        • (edit) maven-shade-plugin/src/test/java/org/apache/maven/plugins/shade/relocation/SimpleRelocatorTest.java
        Show
        hudson Hudson added a comment - SUCCESS: Integrated in Jenkins build maven-plugins #8621 (See https://builds.apache.org/job/maven-plugins/8621/ ) MSHADE-240 support relocation pom.properties and pom.xml descriptors in shaded jars (rfscholte: http://svn.apache.org/viewvc/?view=rev&rev=1779644 ) (add) maven-shade-plugin/src/it/ MSHADE-240 _reloc-mavenfiles (add) maven-shade-plugin/src/it/ MSHADE-240 _reloc-mavenfiles/pom.xml (add) maven-shade-plugin/src/it/ MSHADE-240 _reloc-mavenfiles/verify.groovy (edit) maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/relocation/SimpleRelocator.java (edit) maven-shade-plugin/src/test/java/org/apache/maven/plugins/shade/relocation/SimpleRelocatorTest.java
        Hide
        tmortagne Thomas Mortagne added a comment -

        I haven't activated it by default

        Would have been nice. Most of the issues I have are with dependencies I don't control on and which don't care about those files so they will never thing about enabling this.

        Show
        tmortagne Thomas Mortagne added a comment - I haven't activated it by default Would have been nice. Most of the issues I have are with dependencies I don't control on and which don't care about those files so they will never thing about enabling this.
        Hide
        rfscholte Robert Scholte added a comment -

        I know cases where these files are searched for on the classpath. So relocating will make it fail in such cases. Current behavior seems reasonable to me, also because it is simple: a pure merge of jar files.

        Show
        rfscholte Robert Scholte added a comment - I know cases where these files are searched for on the classpath. So relocating will make it fail in such cases. Current behavior seems reasonable to me, also because it is simple: a pure merge of jar files.
        Hide
        tmortagne Thomas Mortagne added a comment - - edited

        I know cases where these files are searched for on the classpath

        Yes my use case is exactly about that. But what you don't seems to understand is that in case of relocation these files don't match what is in the jar anymore. Again as I explained in the issue description those files are misleading any tools that search for those files to find out what is in the JAR. In other words since the JAR does not contain the classes of somegroupid:someartifactid:someversion it should not contain a descriptor indicating it's somegroupid:someartifactid:someversion because it's simply not true anymore.

        Show
        tmortagne Thomas Mortagne added a comment - - edited I know cases where these files are searched for on the classpath Yes my use case is exactly about that. But what you don't seems to understand is that in case of relocation these files don't match what is in the jar anymore. Again as I explained in the issue description those files are misleading any tools that search for those files to find out what is in the JAR. In other words since the JAR does not contain the classes of somegroupid:someartifactid:someversion it should not contain a descriptor indicating it's somegroupid:someartifactid:someversion because it's simply not true anymore.
        Hide
        rfscholte Robert Scholte added a comment -

        Your situation is exactly the opposite of my usecase. In my case it must find the version of a certain dependency, no matter shaded or not. So it all depends on the implementation, hence it is up to the developer to decide if these files should be relocated or not.

        Show
        rfscholte Robert Scholte added a comment - Your situation is exactly the opposite of my usecase. In my case it must find the version of a certain dependency, no matter shaded or not. So it all depends on the implementation, hence it is up to the developer to decide if these files should be relocated or not.
        Hide
        tmortagne Thomas Mortagne added a comment -

        IMO your use case is covered by what I suggested in the issue description:

        An alternative is to move them in some other place like /META-INF/shade/maven/<groupid>/<artifactid>/* for example, so that you still keep information about what has been shaded.

        As I said since the JAR does not contain what it's supposed to contain it should not screen to still being what it used to be. But in your use case you could look at both shaded and not shaded descriptors. In my case I have no way to know what kind of JAR it is (and I'm not even supposed to know what shade plugin is).

        Show
        tmortagne Thomas Mortagne added a comment - IMO your use case is covered by what I suggested in the issue description: An alternative is to move them in some other place like /META-INF/shade/maven/<groupid>/<artifactid>/* for example, so that you still keep information about what has been shaded. As I said since the JAR does not contain what it's supposed to contain it should not screen to still being what it used to be. But in your use case you could look at both shaded and not shaded descriptors. In my case I have no way to know what kind of JAR it is (and I'm not even supposed to know what shade plugin is).

          People

          • Assignee:
            rfscholte Robert Scholte
            Reporter:
            tmortagne Thomas Mortagne
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development