Uploaded image for project: 'Maven Assembly Plugin'
  1. Maven Assembly Plugin
  2. MASSEMBLY-64

jar-with-dependencies has a last-one-copies-wins policy which can fail signed jars

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 2.0.1
    • 2.1
    • None
    • None

    Description

      I've configured the plugins like this:

      <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-jar-plugin</artifactId>
      <configuration>
      <archive>
      <manifest>
      <mainClass>ggg.GGGStandaloneApp</mainClass>
      <addClasspath>true</addClasspath>
      </manifest>
      </archive>
      </configuration>
      </plugin>
      <plugin>
      <artifactId>maven-assembly-plugin</artifactId>
      <configuration>
      <descriptorId>jar-with-dependencies</descriptorId>
      <archive> <!-- Please document this -->
      <manifest>
      <mainClass>ggg.GGGStandaloneApp</mainClass>
      </manifest>
      </archive>
      </configuration>
      </plugin>

      BTW: Please document the archive option in the assembly plugin on the assembly site, it took me a while of trial and error to find it.

      However the application doesn't work yet, because:
      Exception in thread "main" java.lang.SecurityException: no manifiest section for signature file entry javax/activation/D
      ataContentHandlerFactory.class
      at sun.security.util.SignatureFileVerifier.verifySection(Unknown Source)
      at sun.security.util.SignatureFileVerifier.processImpl(Unknown Source)
      at sun.security.util.SignatureFileVerifier.process(Unknown Source)
      at java.util.jar.JarVerifier.processEntry(Unknown Source)
      ...

      It looks like it's because the everything in the META-INF directory have a last-one-copied-wins policy.
      Jar-jar would also solve this of course.

      PS: I am also using acegisecurity, so I belive you can replicate this issue by making an assembly of a HelloWorld dependend on acegi & activation.

      Attachments

        Issue Links

          Activity

            Found a fix:
            exclude
            /META-INF/*.RSA
            /META-INF/*.SF
            /META-INF/*.rsa
            /META-INF/*.sf
            Problem solved.

            Please note that the fact that acegi (and some of the sun jars) are signed also gives problems with the webstart plugin.

            ge0ffrey.desmet Geoffrey De Smet added a comment - Found a fix: exclude /META-INF/*.RSA /META-INF/*.SF /META-INF/*.rsa /META-INF/*.sf Problem solved. Please note that the fact that acegi (and some of the sun jars) are signed also gives problems with the webstart plugin.
            elefkof Melloware added a comment -

            Can you please post the exact example how to get around this? I have the exact same problem.

            elefkof Melloware added a comment - Can you please post the exact example how to get around this? I have the exact same problem.

            Benjamin.Keil also contacted me for this problem.
            Currently I just remove them with winrar afterwards, I don't need the functionality often.

            ge0ffrey.desmet Geoffrey De Smet added a comment - Benjamin.Keil also contacted me for this problem. Currently I just remove them with winrar afterwards, I don't need the functionality often.
            elefkof Melloware added a comment -

            I have this need OFTEN.

            I hope this bug is attended to since anyone doing anythign with Apache Axis that needs javax.activation and wants to build an executable uberjar will have this problem, since the activation jar has these *RSA and *.SF files.

            elefkof Melloware added a comment - I have this need OFTEN. I hope this bug is attended to since anyone doing anythign with Apache Axis that needs javax.activation and wants to build an executable uberjar will have this problem, since the activation jar has these *RSA and *.SF files.

            Implementing the exclusing of the META-INF's shouldn't be to hard.
            If none of the Maven guys have the time, maybe we can provide a patch?
            I got some other things on my mind, but if it's isn't fixed in a few weeks, I 'll provide a fix according to the development guidelines.

            ge0ffrey.desmet Geoffrey De Smet added a comment - Implementing the exclusing of the META-INF's shouldn't be to hard. If none of the Maven guys have the time, maybe we can provide a patch? I got some other things on my mind, but if it's isn't fixed in a few weeks, I 'll provide a fix according to the development guidelines.
            nramirez Nap Ramirez added a comment -

            The reason why you get that SecurityException when running the uberjar is because of all the security files in META-INF/ of every dependency accumulates in the META-INF/ of the uberjar when assembly:assembly is used with the jar-with-dependencies descriptor. This happens because assembling using jar-with-dependencies causes maven to unpack all the dependencies (defaults to true as specified in the ${assembly.dependencySets.dependency.unpack} of jar-with-dependencies.xml) at the same directory where the uberjar is assembled.

            Here are some solutions without removing the security files (removing security files might have license issues):

            A simple fix would be to provide an assembly descriptor similar to the jar-with-dependencies.xml and modify ${assembly.dependencySets.dependency.unpack} to false so that the security files in the META-INF/ of every dependency wouldn't mix into the META-INF/ of the uberjar.

            Another fix also would be to provide an assembly descriptor similar to the jar-with-dependencies.xml and modify ${assembly.dependencySets.dependencySet.outputDirectory} to a directory other than / so that the security files in the META-INF/ of every dependency would accumulate in the specified directory, and thus wouldn't mix into the META-INF/ of the uberjar. But I doubt that this would work all the time. it may have classpath issues (for this issue, the manifest should be modified to provide the classpath).

            nramirez Nap Ramirez added a comment - The reason why you get that SecurityException when running the uberjar is because of all the security files in META-INF/ of every dependency accumulates in the META-INF/ of the uberjar when assembly:assembly is used with the jar-with-dependencies descriptor. This happens because assembling using jar-with-dependencies causes maven to unpack all the dependencies (defaults to true as specified in the ${assembly.dependencySets.dependency.unpack} of jar-with-dependencies.xml) at the same directory where the uberjar is assembled. Here are some solutions without removing the security files (removing security files might have license issues): A simple fix would be to provide an assembly descriptor similar to the jar-with-dependencies.xml and modify ${assembly.dependencySets.dependency.unpack} to false so that the security files in the META-INF/ of every dependency wouldn't mix into the META-INF/ of the uberjar. Another fix also would be to provide an assembly descriptor similar to the jar-with-dependencies.xml and modify ${assembly.dependencySets.dependencySet.outputDirectory} to a directory other than / so that the security files in the META-INF/ of every dependency would accumulate in the specified directory, and thus wouldn't mix into the META-INF/ of the uberjar. But I doubt that this would work all the time. it may have classpath issues (for this issue, the manifest should be modified to provide the classpath).
            nramirez Nap Ramirez added a comment -

            Oh wait, I take that back. According to http://java.sun.com/docs/books/tutorial/deployment/jar/downman.html the classpath points to somewhere outside the uberjar. Therefore, the jars inside the uberjar can only be seen if located programmatically (not good). When exploded to another directory other than /, however, the packaging of the dependencies would mess up. Thus making both my suggestions void. In this case, exploding everything in the uberjar's / in order to make the uberjar executable will work--only that the security files will prevent the uberjar to execute if signed jars were used. Will removing the security files raise any license issues?

            nramirez Nap Ramirez added a comment - Oh wait, I take that back. According to http://java.sun.com/docs/books/tutorial/deployment/jar/downman.html the classpath points to somewhere outside the uberjar. Therefore, the jars inside the uberjar can only be seen if located programmatically (not good). When exploded to another directory other than /, however, the packaging of the dependencies would mess up. Thus making both my suggestions void. In this case, exploding everything in the uberjar's / in order to make the uberjar executable will work--only that the security files will prevent the uberjar to execute if signed jars were used. Will removing the security files raise any license issues?
            nramirez Nap Ramirez added a comment -

            The attached patch fixes this issue, as well as MASSEMBLY-74. As a summary, when assembling a 'jar-with-dependencies', it strips the security files (*.RSA, *.DSA, *.SF) and updates the uberjar's MANIFEST.MF with the something the user provided (using ${project.build.plugins.plugin.configuration.achive.manifestFile}) or as specified in the configuration (${project.build.plugins.plugin.configuration.achive.manifest}). If no MANIFEST.MF is specified, a default is generated by plexus.

            nramirez Nap Ramirez added a comment - The attached patch fixes this issue, as well as MASSEMBLY-74 . As a summary, when assembling a 'jar-with-dependencies', it strips the security files (*.RSA, *.DSA, *.SF) and updates the uberjar's MANIFEST.MF with the something the user provided (using ${project.build.plugins.plugin.configuration.achive.manifestFile}) or as specified in the configuration (${project.build.plugins.plugin.configuration.achive.manifest}). If no MANIFEST.MF is specified, a default is generated by plexus.

            Applied Patch.. Thanks

            aramirez Allan Q. Ramirez added a comment - Applied Patch.. Thanks

            Whatever the version of maven-assembly-plugin I'm using, whether it is 2.1 or 2.2-beta-1, I still have that very issue and get the following exception when trying to run my jar:

            Exception in thread "main" java.lang.SecurityException: no manifiest section for signature file entry javax/activation/DataContentHandlerFactory.class
            at sun.security.util.SignatureFileVerifier.verifySection(SignatureFileVerifier.java:377)
            at sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:231)
            at sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:176)
            at java.util.jar.JarVerifier.processEntry(JarVerifier.java:233)
            at java.util.jar.JarVerifier.update(JarVerifier.java:188)
            at java.util.jar.JarFile.initializeVerifier(JarFile.java:325)
            at java.util.jar.JarFile.getInputStream(JarFile.java:390)
            at sun.misc.URLClassPath$JarLoader$1.getInputStream(URLClassPath.java:620)
            at sun.misc.Resource.cachedInputStream(Resource.java:58)
            at sun.misc.Resource.getByteBuffer(Resource.java:113)
            at java.net.URLClassLoader.defineClass(URLClassLoader.java:249)
            at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
            at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
            at java.security.AccessController.doPrivileged(Native Method)
            at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
            at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
            at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
            at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
            at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)

            sarbogast Sebastien Arbogast added a comment - Whatever the version of maven-assembly-plugin I'm using, whether it is 2.1 or 2.2-beta-1, I still have that very issue and get the following exception when trying to run my jar: Exception in thread "main" java.lang.SecurityException: no manifiest section for signature file entry javax/activation/DataContentHandlerFactory.class at sun.security.util.SignatureFileVerifier.verifySection(SignatureFileVerifier.java:377) at sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:231) at sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:176) at java.util.jar.JarVerifier.processEntry(JarVerifier.java:233) at java.util.jar.JarVerifier.update(JarVerifier.java:188) at java.util.jar.JarFile.initializeVerifier(JarFile.java:325) at java.util.jar.JarFile.getInputStream(JarFile.java:390) at sun.misc.URLClassPath$JarLoader$1.getInputStream(URLClassPath.java:620) at sun.misc.Resource.cachedInputStream(Resource.java:58) at sun.misc.Resource.getByteBuffer(Resource.java:113) at java.net.URLClassLoader.defineClass(URLClassLoader.java:249) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
            jaxzin Brian Jackson added a comment - - edited

            Anyone else that just wants to know how to customize the jar-with-dependencies descriptor to fix this problem (like I did) here's what you need:

            <assembly>
            <id>jar-with-dependencies</id>
            <formats>
            <format>jar</format>
            </formats>
            <includeBaseDirectory>false</includeBaseDirectory>
            <dependencySets>
            <dependencySet>
            <outputDirectory></outputDirectory>
            <outputFileNameMapping></outputFileNameMapping>
            <unpack>true</unpack>
            <scope>runtime</scope>
            <unpackOptions>
            <excludes>
            <exclude>/META-INF/*.RSA</exclude>
            <exclude>/META-INF/*.DSA</exclude>
            <exclude>/META-INF/*.SF</exclude>
            <exclude>/META-INF/*.rsa</exclude>
            <exclude>/META-INF/*.dsa</exclude>
            <exclude>/META-INF/*.sf</exclude>
            </excludes>
            </unpackOptions>
            </dependencySet>
            </dependencySets>
            <fileSets>
            <fileSet>
            <directory>target/classes</directory>
            <outputDirectory></outputDirectory>
            </fileSet>
            </fileSets>
            </assembly>

            jaxzin Brian Jackson added a comment - - edited Anyone else that just wants to know how to customize the jar-with-dependencies descriptor to fix this problem (like I did) here's what you need: <assembly> <id>jar-with-dependencies</id> <formats> <format>jar</format> </formats> <includeBaseDirectory>false</includeBaseDirectory> <dependencySets> <dependencySet> <outputDirectory></outputDirectory> <outputFileNameMapping></outputFileNameMapping> <unpack>true</unpack> <scope>runtime</scope> <unpackOptions> <excludes> <exclude>/META-INF/*.RSA</exclude> <exclude>/META-INF/*.DSA</exclude> <exclude>/META-INF/*.SF</exclude> <exclude>/META-INF/*.rsa</exclude> <exclude>/META-INF/*.dsa</exclude> <exclude>/META-INF/*.sf</exclude> </excludes> </unpackOptions> </dependencySet> </dependencySets> <fileSets> <fileSet> <directory>target/classes</directory> <outputDirectory></outputDirectory> </fileSet> </fileSets> </assembly>

            People

              aramirez Allan Q. Ramirez
              ge0ffrey.desmet Geoffrey De Smet
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Time Tracking

                  Estimated:
                  Original Estimate - 5h
                  5h
                  Remaining:
                  Time Spent - 1.5h Remaining Estimate - 3.5h
                  3.5h
                  Logged:
                  Time Spent - 1.5h Remaining Estimate - 3.5h
                  1.5h