[
https://issues.apache.org/jira/browse/SLING-830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775006#action_12775006
]
Peter Chiochetti commented on SLING-830:
----------------------------------------
I see this again, current trunk 834084 build from fresh checkout fails in
"org.apache.sling.launchpad.webapp.integrationtest" after warnings when
starting jetty.
A simple "java -jar target/org.apache.sling.launchpad.app-6-SNAPSHOT.jar -c
sling -f -" in launchpad/app will not succeed and produce the exactly same
message from top of this issue. java version "1.6.0_12" on debian 5. no eclipse
here.
Doing a "mvn clean install" in launchpad/base first and then the same in app
again lets me start the app in launchpad.
> Startup failure when after a full build of Sling.
> -------------------------------------------------
>
> Key: SLING-830
> URL: https://issues.apache.org/jira/browse/SLING-830
> Project: Sling
> Issue Type: Bug
> Components: General
> Affects Versions: Launchpad Webapp 5, Launchpad Base 2.0.4, Launchpad App 5
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Priority: Critical
> Fix For: Launchpad Webapp 5, Launchpad Base 2.0.4, Launchpad App 5
>
>
> When doing a full build of Sling from the root of the trunk using the Maven
> Reactor, the final launchpad/app JAR file cannot be started because a JAR is
> said to not be verifiable (see also [1]):
> sling/launchpad/app/target# java -jar
> org.apache.sling.launchpad.app-5-incubator-SNAPSHOT.jar -c sling -f -
> Exception in thread "main" java.lang.SecurityException: Invalid signature
> file digest for Manifest main attributes
> at
> sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:221)
> at
> sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:176)
> at java.util.jar.JarVerifier.processEntry(JarVerifier.java:277)
> at java.util.jar.JarVerifier.update(JarVerifier.java:188)
> at java.util.jar.JarFile.initializeVerifier(JarFile.java:321)
> at java.util.jar.JarFile.getInputStream(JarFile.java:386)
> at sun.misc.URLClassPath$JarLoader$2.getInputStream(URLClassPath.java:689)
> at sun.misc.Resource.cachedInputStream(Resource.java:59)
> at sun.misc.Resource.getByteBuffer(Resource.java:154)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:249)
> at java.net.URLClassLoader.access$000(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:307)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
> Could not find the main class: org.apache.sling.launcher.app.main.Main.
> Program will exit.
> It seems that on a full build, the signature files from the Eclipse
> HttpService Bridge are included, which cause the JAR class loader to try to
> verify the jar file, which of course fails. The files are META-INF/ECLIPSE.SF
> and META-INF/ECLIPSE.RSA. If these files are not in the final JAR, it starts
> up flawlessly.
> When doing a single-module build of the the launchpad/base first and then
> launchpad/app, the JAR file is correctly created without these Eclipse
> signature files. So it looks like this problem is related to the reactor
> build. In addition, the launchpad/base build is defined to ignore the
> META-INF folders of the included libraries. This does not seem to be obeyed
> in the reactor build case.
> So, I assume this is related to the maven-dependency-plugin being used to
> glue the launchpad/base library together is not the correct version, since
> multiple versions are used throughout the build process and there is no
> managed version number in the parent pom.
> Adding the maven-dependency-plugin to the parent pom's pluginManagement with
> version 2.0 and removing all explicit version references actually fixes this
> problem and the resulting jar starts correctly, even after a reactor build.
> [1] http://markmail.org/message/4fxvcvm4jhiveb7l
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
