I’ve created a sample project that exhibits this issue, so any assistance is appreciated.
If I do a build on contact-service, I get NoSuchMethodError in the testFindByContactId and testHandleNotFound. If I import the project into IDEA, or run it in a Maven build, the test passes without issue.
Here is the output from gradle -v.
------------------------------------------------------------ Gradle 1.5 ------------------------------------------------------------
Gradle build time: Wednesday, March 27, 2013 1:51:06 PM UTC Groovy: 1.8.6 Ant: Apache Ant™ version 1.8.4 compiled on May 22 2012 Ivy: 2.2.0 JVM: 1.7.0_17 (Oracle Corporation 23.7-b01) OS: Windows 8 6.2 amd64
I’m using JDK7, but notice that a log message states Compiling with JDK 6 Java Compiler API. Don’t know if that’s the issue. I’ve set my source and target compatibility explicitly, although 1.7 appears to be the default if I do a ‘gradle props’ on my project.
Any assistance/guidance greatly appreciated
The repo is at https://bitbucket.org/mikezx6r/gradle-runtime-test-issue. Please let me know if you have issues getting access to it.
Thanks, Mike
This is probably because there are different versions of hamcrest in play.
I spent some time just yesterday fixing this problem in one of our projects where hamcrest was updated to version 1.3.
But junit, powermock and mockito were still the old versions - and they include (in their jar-files) the hamcrest version 1.1 classes.
So while your Eclipse classpath may make you see hamcrest 1.3 classes first, the 1.1 classes may come first at runtime and cause this error.
For hamcrest 1.3: * junit: should be 4.11+ * powermock: should be 1.5+ * mockito: should be 1.9.5+
Hope this helps.
Thank you for the response. If I was getting an older version, wouldn’t I expect to see it in the dependencies list? All I’m seeing is hamcrest 1.3.
I did try updating mockito to 1.9.5 (previously 1.9.0), and I’m also forcing module versions to try and ensure I’m getting the versions I want.
I thought Gradle was better at handling this, and the default is to take a later version. I’ve turned on fail if there’s a conflict, so if 1.1 was trying to ‘sneak’ in, again, I’d expect Gradle to report it as a conflict.
I’ve stated that Maven works, BUT the pom is not equivalent to the build.gradle. I’ll create an equivalent pom.xml to see if I experience this issue with maven too.
As I wrote, the problem is not the hamcrest 1.1 jar file.
The problem is that classes from hamcrest 1.1 are included in other jar-files. This completely bypasses dependency tracking/control.
Try searching your resolved dependency jars for the class name that causes the problem.
Try ‘gradle dependencyInsight --dependency hamcrest’. This will tell you who pulls in the Hamcrest library. You can then either exclude Hamcrest altogether (if you are happy with the Hamcrest that’s bundled with JUnit) or enforce a particular version.
PS: Consider using JUnit 4.11 or higher, which bundles (parts of) Hamcrest 1.3.
@Jesper I’ll perhaps resort to that. I’ve tried forcing the version of hamcrest, and upgraded mockito to 1.9.5.
@Peter I’m already using JUnit 4.11 and according to insight, only 1.3 is being brought in.
I will continue to remove things from my posted repo source to try and narrow down the issue, but if you think there might be something obvious in the gradle.build, please browse and provide feedback.
Thank you all for your assistance.
Finally figured it out, and @Jesper was right. I’m including Mockito-all 1.9.5, and for some reason, it defines an AllOf in the org.hamcrest package which must be superseding the actual org.hamcrest.AllOf.
This didn’t occur with Maven, or Idea, so they must have been putting them in a different order, and seeing the hamcrest version first.
Once I switch it to mockito-core, all works as expected.
Again, thank you for the help and hints.
Thank you for posting this. Just replaced mockito-all:2.0.2-beta with mockito-core:2.0.2-beta and things are back to normal, you saved me a lot of work.