Gradle 1.8-rc-1 NullPointerException while executing 'gradle idea'

(Jörn Huxhorn) #1
FAILURE: Build failed with an exception.
  * What went wrong:
Execution failed for task ':foo:bar:ideaModule'.
> Problems reading data from Binary store in /private/var/folders/rb/lvpw6l952pg1g85m4p3jzgf80000gp/T/gradle311424350957547533.bin (exist: true)


(Jörn Huxhorn) #2

Ok… I tried to delete the caches in ~/.gradle and [projectRoot]/.gradle. After that I rebooted and cleaned all temporary files. Nothing helped.

Interestingly, I don’t have this problem in my personal projects, just the company one. Because of this, I can’t give you access to the files.

The failure is always happening in the same module.

Reverting to 1.7 fixed the problem.

Hope this helps.

(Jörn Huxhorn) #3

Any news on this?

(Ben Manes) #4

Looks similar to the Eclipse NPE

(Jörn Huxhorn) #5

Definitely. Good to know that I’m not the only one. :slight_smile:

(Szczepan Faber) #6

The failure is always happening in the same module.

Can you run gradle dependencies in this module and put the results in gist/pastebin? I’m curious if there’s anything interesting about the dependencies.

(Jörn Huxhorn) #7

The only unusual thing/problem is that one of the dependencies is missing a version.

The build is a multi-project build and the dependency in question refers to one of the contained projects.

It looks like this: ‘x:y:unspecified’

I guess this is indeed the problem… but I won’t change anything right now so I’ll be able to confirm your fix.

(Szczepan Faber) #8

Can you help debugging this issue?

  1. Does the idea task also fail when when you run it only for this failing module? 2. What if you remove this dependency temporarily and run the idea task, does the task still fails?


(Jörn Huxhorn) #9
  1. yes 2. removing the dependency fixes the problem.

(Szczepan Faber) #10

I’ve tried to repro this scenario with some unspecified versions, but it seemed to work fine for me. I suspect there’s some other contributing reason.

Can you try building with this version of Gradle:

We’ve added more diagnostics to understand the problem better.

(Jörn Huxhorn) #11

It says > Could not resolve all dependencies for configuration ‘:foo:bar:compile’.

Unexpected state Evicted for parent node for dependency from javax.mail:mail:1.4.1(default) to javax.activation:activation:1.1.1(compile).

Does that help?

(Ben Manes) #12

I sent Szczepan a private email, wrt the Eclipse problem, that had a similar error message (different dependency) using the diagnostic snapshot.

(Jörn Huxhorn) #13

I just hope it means more Szczepan than to me. That dependency looks so innocent. You sent him your build without source, right?

(Ben Manes) #14

yes, with modifications to work externally. Oddly, after a few tweaks it imported fine. The biggest difference that I can tell is that it didn’t resolve using the Artifactory plugin and instead used public repositories. My best guess now is that the Artifactory plugin may be interacting with it oddly, but I haven’t explored that yet.

(Jörn Huxhorn) #15

We are running against a company-internal Nexus repository instead of Maven Central… Hm.

(Szczepan Faber) #16


We have pushed the fix. Do you mind trying out this gradle version:

(Jörn Huxhorn) #17

I can confirm that this fixed the issue, thank!

Just out of curiosity… what was wrong/the cause?