tschulte/gradle-jnlp-plugin

SignJars fails with Java 8u144

amake opened this issue · 9 comments

amake commented

I am encountering a problem running the SignJars task. The exception thrown (below) is consistent with an issue that was introduced in 8u141 but supposedly fixed in 8u144; nevertheless I am unable to sign a particular JAR (org.eclipse.jgit:org.eclipse.jgit:4.8.0.201706111038-r) on my project, and it seems the same issue is causing your unit tests to fail when running ./gradlew test:

Caused by: java.lang.SecurityException: digest missing for org/jdesktop/jxlayer/JXLayer$1.class
	at de.gliderpilot.gradle.jnlp.SignJarsTask.copyUnsignAndAlterManifest_closure7_closure13(SignJarsTask.groovy:110)
	at de.gliderpilot.gradle.jnlp.SignJarsTask.copyUnsignAndAlterManifest_closure7(SignJarsTask.groovy:95)
	at de.gliderpilot.gradle.jnlp.SignJarsTask.copyUnsignAndAlterManifest(SignJarsTask.groovy:93)
	at de.gliderpilot.gradle.jnlp.SignJarsTask.signJars_closure3_closure9(SignJarsTask.groovy:49)
	at groovyx.gpars.pa.GParsPoolUtilHelper.eachParallelPA_closure8(GParsPoolUtilHelper.groovy:192)
	at groovyx.gpars.extra166y.AbstractParallelAnyArray$OUPap.leafApply(AbstractParallelAnyArray.java:640)
	at groovyx.gpars.extra166y.PAS$FJOApply.atLeaf(PAS.java:147)
	at groovyx.gpars.extra166y.PAS$FJBase.internalCompute(PAS.java:118)
	at groovyx.gpars.extra166y.PAS$FJBase.compute(PAS.java:106)
	at jsr166y.RecursiveAction.exec(RecursiveAction.java:148)
	at jsr166y.ForkJoinTask.doExec(ForkJoinTask.java:305)
	at jsr166y.ForkJoinWorkerThread.execTask(ForkJoinWorkerThread.java:575)
	at jsr166y.ForkJoinPool.scan(ForkJoinPool.java:755)
	at jsr166y.ForkJoinPool.work(ForkJoinPool.java:617)
	at jsr166y.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:369)

I'm a bit at a loss as to how to deal with this other than sticking with 8u121.

tschulte commented

Thank you for reporting this issue.

The problem was something different than the problem described in the StackOverflow-link.

Normally, when signing a jar file created with default settings (i.e. without any fancy manifest-entries), the manifest does not contain any named entries before signing and one named entry for each .class file after signing

Name: x/y/z/Classname.class
SHA-256-Digest: /AGKYLRt2bYXrzhYMPFUgaA0/hjZ6Rzf3X7hLZ/GP7w=

But some jars already have named attributes in their manifests.

The gradle-jnlp-plugin removes all named entries .*-Digest and some main attributes of the MANIFEST.MF to prevent this type of errors. For this it uses java.util.jar.JarFile.getManifest().

But it did alter the manifest object of the original jar file to create a new jar file. But it seems, that 8u141 does has an issue with this.

I have created a fix which does create a copy of the manifest instead of altering it directly. Now it works.

Once Travis has build the version, there should be a new bugfix version available that fixes this issue.

  • 👍1
tschulte commented

Travis has some issues building the version because of some ssl problems. The release of the new version will be delayed until that is resolved.

amake commented

I'm unable to actually get the artifacts from plugins.gradle.org:

> Could not resolve all files for configuration ':classpath'.
   > Could not find gradle.plugin.de.gliderpilot.gradle.jnlp:gradle-jnlp-plugin:1.2.2.
     Searched in the following locations:
         https://plugins.gradle.org/m2/gradle/plugin/de/gliderpilot/gradle/jnlp/gradle-jnlp-plugin/1.2.2/gradle-jnlp-plugin-1.2.2.pom
         https://plugins.gradle.org/m2/gradle/plugin/de/gliderpilot/gradle/jnlp/gradle-jnlp-plugin/1.2.2/gradle-jnlp-plugin-1.2.2.jar

Is this their problem, not yours?

Edit: Nevermind, I'm seeing it now.

tschulte commented

Maybe some caching issue? Good to know it works now.

mauromol commented

There's some problem indeed. As soon as I start using the jnlp-war plugin (with plugins { id "de.gliderpilot.jnlp-war" version "1.2.2" } syntax), if I request version 1.2.2 of that plugin I get the above "Could not resolve etc." error. Please note, it's NOT the jnlp plugin to cause Gradle to emit that error, but the jnlp-war plugin!
If I use the jnlp-war plugin 1.2.1, all works fine.
Perhaps you didn't publish the 1.2.2. version of jnlp-war plugin correctly at plugins.gradle.org. Just a guess...

amake commented

To be clear, my issue was limited to the jnlp plugin, and it seemed to be a mere response-caching issue as --refresh-dependencies fixed it in the end. I can't speak to the jnlp-war plugin.

mauromol commented

In my use case, instead, --refresh-dependencies does not help... :(
If I just use the jnlp plugin version 1.2.2, however, I never had problems.
So, let's hope Tobias can figure this out.

tschulte commented

I think the issue is that both plugins are in the same jar file. Gradle seems to have a problem with this, when using the incubating plugins notation.

AFAIK the new plugins syntax has some limitations. E.g. it is not possible to use the same block both in the root project and any subproject.

I will have to investigate further and create an issue for this, once I know how it should work.

In the meantime, please use the following workaround:

in the rootProject/build.gradle:

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath "de.gliderpilot.gradle.jnlp:gradle-jnlp-plugin:1.2.2"
    }
}

and in the subprojects

apply plugin: "de.gliderpilot.jnlp"

or

apply plugin: "de.gliderpilot.jnlp-war"

That has the additional advantage, that you only need to define the version of the plugin once.