mockito-core hamcrest dependency doesn't play nice with hamcrest

[GoogleCodeExporter]

The junit guys have removed "junit-dep"; if I want hamcrest I need to specify 
it myself (this is good).

The hamcrest guys have created a "hamcrest-integration" jar which brings in a 
tree of dependencies that one needs to safely use hamcrest (this is good).

Mockito provides mockito-core which has a *specific* dependency on 
hamcrest-core (1.1).  This overrides the transitive dependency on hamcrest-core 
that hamcrest-integration brings in.

Could you make mockito-core depend on hamcrest-integration instead of 
hamcrest-core - then everyone's instructions will play nicely together.

Thanks!

Original issue reported on code.google.com by jatw...@linuxstuff.org on 11 Jan 2013 at 7:43

[GoogleCodeExporter]

Hi,

Thx for reporting, Hamcrest is begining to be an urgent matter as times goes 
by. We are still a bit locked up at the moment by ancient version and compile 
time compatibility with previous binaries, that's why we still stick to 
hamcrest 1.1.

But we definitely need to look in the matter. I'll hope we can spend time on it 
for the next release.

Cheers,
Brice

Original comment by brice.du...@gmail.com on 14 Jan 2013 at 8:21

[GoogleCodeExporter]

Hmmm.. There's always the option of marking hamcrest as provided, but that 
would be a breaking change for mockito users.

Original comment by jatw...@linuxstuff.org on 14 Jan 2013 at 9:01

[GoogleCodeExporter]

yes that could be a problem.

Original comment by brice.du...@gmail.com on 29 Apr 2013 at 4:13

• Added labels: Matchers, Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I just ran into this issue as well. It's quite confusing when your tests fail 
with a NoSuchMethodError from inside the assertThat call. I devised this 
example project that shows how the order of the dependencies matter: 
https://github.com/chrisvest/hamcrest-cp-bug

Original comment by mr.chris...@gmail.com on 11 Jun 2014 at 11:14

[GoogleCodeExporter]

Hey thanks for this example :)
You may want to Create a wiki page with that content. Entitled with something 
like Common issues.

Cheers

Original comment by brice.du...@gmail.com on 27 Jun 2014 at 3:20

[GoogleCodeExporter]

Perhaps this is a good reason to use AssertJ for your own tests.  No conflicts, 
and it results in a more "fluent" assertion.

Original comment by davidmic...@gmail.com on 27 Jun 2014 at 3:31

[GoogleCodeExporter]

Indeed !

Original comment by brice.du...@gmail.com on 27 Jun 2014 at 3:35