Execute the following test somewhere in the engine-tests project to reproduce:
@Test
public void test() {
org.junit.Assert.assertThat(42, org.hamcrest.CoreMatchers.is(43));
}
Instead of
java.lang.AssertionError:
Expected: is <43>
but: was <42>
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
I am getting
java.lang.NoSuchMethodError: org/hamcrest/Matcher.describeMismatch(Ljava/lang/Object;Lorg/hamcrest/Description;)V
The issue seems to be in the dependencies of the test project:
compile group: 'junit', name: 'junit', version: '4.12'
compile group: 'org.mockito', name: 'mockito-all', version: '1.10.19'
compile group: 'org.jboss.shrinkwrap', name: 'shrinkwrap-depchain-java7', version: '1.1.3'
The problem here is, that mockito-all bundles hamcrest 1.1 but junit has a transitive dependency to hamcrest 1.3. The IDE picks up the hamcrest version from junit but the tests get executed with the one from mockito which is not compatible to junit 4.11+ See also [1] and [2].
It would be interesting to know if this is an Eclipse-only problem and maybe can be fixed with a workspace change or if it also affects our IntelliJ developers.
A possible solution would be to import hamcrest at first, e.g. like
compile group: 'org.hamcrest', name: 'hamcrest-core', version: '1.3'
compile group: 'junit', name: 'junit', version: '4.12'
compile group: 'org.mockito', name: 'mockito-all', version: '1.10.19'
compile group: 'org.jboss.shrinkwrap', name: 'shrinkwrap-depchain-java7', version: '1.1.3'
but we may also consider to move away from mockito-all and use mockito-core instead, maybe even in the latest version 2.2 which has some improvements like better java 8 support, e.g. mocking default method. [3]
[1] https://tedvinke.wordpress.com/2013/12/17/mixing-junit-hamcrest-and-mockito-explaining-nosuchmethoderror/
[2] http://stackoverflow.com/questions/15833015/nosuchmethoderror-with-hamcrest-1-3-junit-4-11
[3] https://github.com/mockito/mockito/wiki/What%27s-new-in-Mockito-2
Left a note on the PR that oddly I get different behavior in IntelliJ - but Jenkins appears to be fine.
Also curious to hear more IDE reports from anybody else able to test. @msteiger & @skaldarnar maybe? @vampcat?
I can verify that I get the same results - NoSuchMethod exception - in IntelliJ.
That being said, @Cervator It is interesting to note that the problem I encountered with DestSol and guava was pretty much identical, with the inclusion of an older version leading to problems. Is there any way to prevent inclusion of old versions of library in gradle, if a newer one is already present?
compile("project") { exclude module: "dependency"} I believe this is how gradle deals with such things. At least it's what I've used in projects
This issue was moved to Wafflemon/Frothleikr#5