[ http://jira.codehaus.org/browse/MASSEMBLY-64?page=comments#action_61420 ]
Napoleon Esmundo C. Ramirez commented on MASSEMBLY-64:
------------------------------------------------------
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).
> jar-with-dependencies has a last-one-copies-wins policy which can fail signed
> jars
> ----------------------------------------------------------------------------------
>
> Key: MASSEMBLY-64
> URL: http://jira.codehaus.org/browse/MASSEMBLY-64
> Project: Maven 2.x Assembly Plugin
> Type: Bug
> Versions: 2.0.1
> Reporter: Geoffrey De Smet
> Fix For: 2.1
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
