Decouple JUnit from Hamcrest

[marcphilipp]

@npryce has nicely summed up the reasons to do this in his blog:
http://www.natpryce.com/articles/000806.html

[kcooney]

Sounds like a good plan. Let's deprecate the APIs that use Matcher on the main branch

[Tibor17]

What about to declare optional dependency of Hamcrest in POM:4.13?
Looks like some API are deprecated and you would force the users include their dependency of Hamcrest.

This means our POM would specify optional dependency:
<dependency> <groupId>org.hamcrest</groupId> <artifactId>hamcrest-core</artifactId> <version>1.3</version> <optional>true</optional> </dependency>
and customer does not receive Hamcrest in his classpath. Therefore the customer will specify it in his POM with the version he likes.

[drjasonharrison]

Will this also resolve the warning that com.netflix.nebula.lint produces:

warning   duplicate-dependency-class         junit:junit:4.12 in configuration ':moduleA:compile' has 21 classes duplicated by org.hamcrest:hamcrest-core:1.3 (use --debug for detailed class list) (no auto-fix available)

nebula-plugins/gradle-lint-plugin#103

[kcooney]

@drjasonharrison I don't think that should happen with JUnit 4.12 (it doesn't ship with Hamcrest classes). Is it possible you depend on multiple versions of JUnit?

In any case, I suggest trying to create a minimal reproducible test case and ask on stackoverflow.com