When I build with 1.10-20131013220027+0000 everything works. When I build with 1.10-20131020220023+0000 I get the following error: :compileJava C:\path\to\java\file\that\accesses\a\jna\interface\Here.java:149: error: cannot access StdCallLibrary
int result = Winmm.INSTANCE.timeBeginPeriod(1);
^
class file for com.sun.jna.win32.StdCallLibrary not found
The Winmm class is from a project dependency. That dependecy depends on JNA 3.3.0 where StdCallLibrary is defined.
There were some temporary issues around that time.
Try:
I updated to 1.10-20131021220032+0000 I tried --refresh-dependencies and it had no effect I deleted ~/.gradle and the .gradle folder in the parent project and the sub-project and still I get the same error.
It’s going to be hard to diagnose this without a reproducible sample.
There weren’t any obvious changes over this time that would affect this.
I understand. The project I am seeing this on is fairly large and complex, and not open. I would have to create a sample that I could share - I suspect that may be time consuming. I will try if nothing is found sooner and the next few builds continue to fail.
The good news is that I have narrowed down the point where the problem was introduced.
The nightly build from 2013-10-19 works The nightly build from 2013-10-20 fails
If gradle is easy to build (and I bet it is 
) I am willing to bisect the commits between those releases to narrow it down further. I have never built gradle from source, and I believe you guys are using git (which I find very non-intuitive compared to Mercurial), but I can probably figure it out.
I build from changeset d0e2a547eca1ceff21af132f3570b0981211b8a1 on the master branch (I’m not familiar with git terminology, so sorry if that’s not the right way to say it) …and it worked
The very next commit on that branch, 581672141877ecccd772cfdc6a945b9ba37b738e, where a bunch of other changes are merged in, fails.
Many thanks, this will help greatly.
Results of bisecting… 581672141877ecccd772cfdc6a945b9ba37b738e bad d0e2a547eca1ceff21af132f3570b0981211b8a1 good 15c47010cfae06dc860734255665d6c6819c6a2f good
15048096f91e107f60cd0f761beca2cd2d1e61c1 (docs failed to build) good
c973203894a0dc42dcff46281668486fd29b3bc1 good
b0c110edc5aa765c89e7779f3d9c213a4e04c065 good
68a6d21de3cf19f8d7f73073ed5c1fc7fd41fe4d bad
3b5c8e63b60f4815744516a6d3834f65ea1df3b5 bad
3b5c8e63b60f4815744516a6d3834f65ea1df3b5 is the first bad commit commit 3b5c8e63b60f4815744516a6d3834f65ea1df3b5 Author: Adam Murdoch adam.murdoch@gradleware.com Date:
Sun Oct 20 18:09:43 2013 +1100
Changed the pom parser so that it orders inherited dependencies after declared dependencies. This was the behaviour previously and seems to be more consistent with what Maven does.
:040000 040000 e39ef3514c835ac9ccf632b1dfe391c9a852d684 b57575c59b5ba5823e5398905fe144371df1dee4 M subprojects
This looks like it is GRADLE-2931, which is present in 1.9-rc-1 and scheduled to be fixed in 1.9-rc-2 (released later this week).