Can a sans-hamcrest junit jar be built please?

[skestle]

I'm an avid user of hamcrest, and it's really confusing for other developers when they get

java.lang.NoSuchMethodError: org.hamcrest.Matcher.describeMismatch(Ljava/lang/Object;Lorg/hamcrest/Description;)V

or some other error because we use a later version of hamcrest. It's usually a simple classpath ordering issue, but it can get in the way a bit.

As we are on a later version, we also use MatcherAssert.assertThat instead of Assert.assertThat (as it gives/gave much better error messages anyhow).

What I would like is just to delete the hamcrest classes after the build. If we have a compatible version of hamcrest for Assert.assertThat() etc, then that will work, if not, then we know what to do anyhow. (as it will show the hamcrest classes. It's quite confusing for a developer the first time they see hamcrest inside junit :))

Cheers

[MichaelHackett]

To some extent, that's what the junit-dep version is, is it not? I just looked and the org.hamcrest.* classes are not in it. However, the JUnit implementations of some matchers (JUnitMatchers and org.junit.internal.matchers.*), and the JUnit assertThat method, are still there.

As you say, ideally the updated Hamcrest version of assertThat could just be adopted, and most of the JUnit matchers can be deprecated or removed in favor of equivalents in Hamcrest lib. Maybe if the compatibility issues in Hamcrest can be worked out in v1.3 that is being tested now.

[dsaff]

I'm closing this, assuming that junit-dep will solve most of the problems, as Michael points out. If this isn't right, I'm happy to re-open