mrunit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexandre Normand (JIRA)" <>
Subject [jira] [Commented] (MRUNIT-208) mrunit unnecessarily depends on mockito-all
Date Wed, 30 Apr 2014 18:32:18 GMT


Alexandre Normand commented on MRUNIT-208:

About mockito, I assumed it was needed because excluding mockito from mrunit produces a runtime
java.lang.NoClassDefFoundError: org/mockito/stubbing/Answer
	at Method)
	at java.lang.ClassLoader.loadClass(
	at sun.misc.Launcher$AppClassLoader.loadClass(
	at java.lang.ClassLoader.loadClass(

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:
>             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
> 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

View raw message