Gradle daemon corrupts resources in snapshot jars

issue-acknowledged
gradle-3512

(Ned Twigg) #1

Gradle Version: 2.14
Operating System: Windows 10 x64
Is this a regression? Unknown

  1. Take a plugin with a resource in its jar file. Have code which pulls it out using the Class.getResource() API.
  2. Deploy this plugin as a snapshot to mavenlocal.
  3. Run a daemon-enabled build that uses the plugin, it’ll work just fine.
  4. Make a change to the plugin, and deploy to mavenlocal again.
  5. Run a daemon-enabled build again, and you’ll find that the resource is not there, with any of these errors:
Caused by: java.io.FileNotFoundException: JAR entry com/diffplug/gradle/pde/template.build.properties not found in C:\Users\ntwigg\.m2\repository\com\diffplug\gradle\goomph\3.0.0-SNAPSHOT\goomph-3.0.0-SNAPSHOT.jar

or 

Caused by: java.util.zip.ZipException: invalid distance too far back

Workaround

  • Kill the daemon in gradlew --stop
  • Run the build again, now it’ll work

(Bhagwat Kumar) #2

Thanks for the workaround. I was stuck with this issue while writing a grails 3.x plugin. I was getting exception like this:

`A problem occurred evaluating root project ‘dummy’.

Failed to apply plugin [id ‘org.grails.grails-web’]
Unable to load [grails.dev.commands.ApplicationCommand] factories from location [META-INF/grails.factories]`


(Lari Hotari) #3

Thanks for reporting the problem.

Does the problem go away if you have this in the beginning of the build.gradle file or in settings.gradle file?

// code for disabling URL caching
new URL("jar:file://valid_jar_url_syntax.jar!/").openConnection().setDefaultUseCaches(false)

Your problem might be related to https://issues.gradle.org/browse/GRADLE-2275 .


(Warren Muller) #4

I’ve had this problem for as long as I can remember on Mac or Linux

  1. Build plugin and install to maven local in one window
  2. Run a build on consuming project in another.

Only solution has always been to run without daemon or stop it first.

I’ve only tested this up to 2.4


(Eric Wendelin) #5

I was hoping that the recent work to close classloaders would solve this, but since it hasn’t been solved yet I’ve filed a new bug GRADLE-3512

Thank you for reporting.

Cheers,
Eric