Future of JUnitMatchers

[UrsMetz]

Almost all factory methods in JUnitMatchers delegate to CoreMatchers from java-hamcrest. There are two matchers left for Throwables (isThrowable and isException) that are not part of hamcrest. The last code usage inside hamcrest-java of JUnitMatchers is removed in #13. There are JavaDoc references in Assume that could easily be changed say that people should use the matchers from java-hamcrest.
I think those two matchers should be moved to hamcrest and JUnitMatchers should be deleted or at least those matchers that only delegate to CoreMatchers should be removed.

[sf105]

My plan was to break up JUnitMatchers. You'll see how it was going in the 2.0.0 branch. But I got diverted.

[UrsMetz]

@sf105 Do you mean the 2.0.0 branch of JavaHamcrest? I couldn't find a 2.0.0 branch of hamcrest-junit.
I think there is nothing left in JUnitMatchers that should be kept/split up (the only reason would be backward compatibility but I gather that this is not the focus as hamcrest-junit as it is relatively new and is more concerned being a "fresh" and maybe compatibility-breaking replacement of the hamcrest-related parts of JUnit). Most of the factory methods are deprecated anyway and only delegate to Hamcrest matchers.

The only unique stuff are the two Throwablematchers: those could be moved to JavaHamcrest.

Or am I missing some point?