[ https://issues.apache.org/jira/browse/MRUNIT-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13985893#comment-13985893 ] 

Alexandre Normand commented on MRUNIT-208:
------------------------------------------

About mockito, I assumed it was needed because excluding mockito from mrunit produces a runtime exception:
{code}
java.lang.NoClassDefFoundError: org/mockito/stubbing/Answer
	at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
	at org.apache.hadoop.mrunit.mapreduce.ReduceDriver.run(ReduceDriver.java:227)
{code}

As for hamcrest, I looked and only test classes where referencing it. You are correct that it won't be brought down transitively and that was the point. Keeping it at test scope avoids imposing hamcrest on projects that depend on mrunit (as long as mrunit doesn't need it to be used downstream). 

> mrunit unnecessarily depends on mockito-all
> -------------------------------------------
>
>                 Key: MRUNIT-208
>                 URL: https://issues.apache.org/jira/browse/MRUNIT-208
>             Project: MRUnit
>          Issue Type: Improvement
>            Reporter: Alexandre Normand
>            Priority: Minor
>         Attachments: MRUNIT-208.patch
>
>
> mrunit depends on mockito but it brings it in as {{mockito-all}}. {{mockito-all}} bundles {{hamcrest}} with it and makes it harder for downstream projects to manage/analyse their dependencies cleanly. 
> I suggest that, to be a good citizen, mrunit declares explicit dependencies on {{mockito-core}} instead as well as a {{test}} scoped dependency on {{hamcrest-core}}.



--
This message was sent by Atlassian JIRA
(v6.2#6252)