Decouple the evolution of Hamcrest and JUnit

[hamcrest]

Decouple the evolution of Hamcrest and JUnit

[npryce]

Repo created at https://github.com/hamcrest/hamcrest-junit

[npryce]

I've copied the JUnit code that depends on Hamcrest and Hamcrest library code that depends on JUnit here: https://github.com/hamcrest/hamcrest-junit and repackaged into org.hamcrest.junit.

I've made the tests pass and set up a Travis CI build here: https://travis-ci.org/hamcrest/hamcrest-junit

I've ensured that the hamcrest-junit code does not pass Hamcrest types to JUnit, so that JUnit can break its dependency on Hamcrest some time in the future.

[npryce]

Still to do - publish to Maven central

[SamirTalwar]

I'm not sure if this is in scope, but I figured it's worth writing down somewhere.

Currently, MatcherAssert.assertThat throws a java.lang.AssertionError on failure with the description built by the matcher. This description can sometimes get pretty massive. By contrast, Assert.assertEquals throws an org.junit.ComparisonFailure, which is a subclass of AssertionError that conveys more information that allows an IDE or something like it to display a diff of the expected and actual results.

Using this sort of thing would be incredibly useful in Hamcrest. However, it's in the JUnit JAR and package structure, not Hamcrest's. Would it be worth creating something like it in hamcrest-junit so that the behaviour (specifically, diffs in the IDE) can be shared between both projects?

[npryce]

That's a good idea but I'm not sure how to do it. AssertThat doesn't see
the expected value, only Matchers that define expected aspects of the
actual value.

It's definitely out of scope for the first release but if you submit a PR
to the hamcrest-junit project we can include it in a later release.

On Wednesday, December 31, 2014, Samir Talwar [email protected]
wrote:

I'm not sure if this is in scope, but I figured it's worth writing down
somewhere.

Currently, MatcherAssert.assertThat throws a java.lang.AssertionError on
failure with the description built by the matcher. This description can
sometimes get pretty massive. By contrast, Assert.assertEquals throws an
org.junit.ComparisonFailure, which is a subclass of AssertionError that
conveys more information that allows an IDE or something like it to display
a diff of the expected and actual results.

Using this sort of thing would be incredibly useful in Hamcrest. However,
it's in the JUnit JAR and package structure, not Hamcrest's. Would it be
worth creating something like it in hamcrest-junit so that the behaviour
(specifically, diffs in the IDE) can be shared between both projects?

—
Reply to this email directly or view it on GitHub
#92 (comment)
.

[SamirTalwar]

Sounds reasonable. Will do soon-ish.

[SamirTalwar]

Are you expecting that the code in org.junit.internal will be rewritten to avoid Hamcrest or that the appropriate functionality will be moved to supporting methods and classes in hamcrest-junit?

[sf105]

Junit should be free of hamcrest at some point. Some of that will be achieved by moving stuff into hamcrest-junit

S

Sent from a device without a keyboard. Please excuse brevity, errors, and embarrassing autocorrections.

On 31 Dec 2014, at 12:04, Samir Talwar [email protected] wrote:

Are you expecting that the code in org.junit.internal will be rewritten to avoid Hamcrest or that the appropriate functionality will be moved to supporting methods and classes in hamcrest-junit?

—
Reply to this email directly or view it on GitHub.

[npryce]

@SamirTalwar - Code in org.junit.internal will have to be rewritten to remove references to Hamcrest. We're not doing anything about internal JUnit implementation details.

[npryce]

hamcrest-junit 1.0.0.0-RC1 is now in Maven central. https://repo1.maven.org/maven2/org/hamcrest/hamcrest-junit/1.0.0.0-RC1/

[marcphilipp]

@npryce Thanks for taking a first step into this direction. I'm one of the maintainers of JUnit. We have had some discussion about modularizing JUnit. junit-hamcrest would have been a potential outcome of this.

@stefanbirkner posted a link to your blog post on the JUnit mailing list. One users replied with a number of concerns: https://groups.yahoo.com/neo/groups/junit/conversations/messages/24626. I share some of those concerns.

@npryce Do you have time to take a look?

[npryce]

I'll join the JUnit group and give my thoughts

On Saturday, January 10, 2015, Marc Philipp [email protected]
wrote:

@npryce https://github.com/npryce Thanks for taking a first step into
this direction. I'm one of the maintainers of JUnit. We have had some
thoughts about modularizing JUnit. junit-hamcrest would have been a
potential outcome of this.

@stefanbirkner https://github.com/stefanbirkner posted a link to your
blog post on the JUnit mailing list. One users replied with a number of
concerns:
https://groups.yahoo.com/neo/groups/junit/conversations/messages/24626. I
share some of those concerns.

@npryce https://github.com/npryce Do you have time to take a look?

—
Reply to this email directly or view it on GitHub
#92 (comment)
.

[npryce]

@marcphilipp - I posted to the JUnit list but got no response. Did you see the message?

[marcphilipp]

@npryce Yes, I did see it. I haven't had time to respond yet, but will do so. I think you have silenced the most pressing concerns.

BTW What's the plan for Hamcrest 2.0? Is there a publicly available "roadmap"?

[npryce]

Great. And (of course) I'd be happy for JUnit maintainers to collaborate on hamcrest-junit.

[marcphilipp]

We're in the midst of a discussion regarding our plans for JUnit 5. We will definitely get back to you. It might take some time, though.

If you need feedback from us, please don't hesitate to ping us over at junit-team/junit or through the mailing list.

[kcooney]

Hi. I am another of the maintainers of JUnit.

Any chance that java-hamcrest can depend on JDK 6, not JDK 7? JUnit is used in a number of environments (GWT, Android, possibly Java ME). Some of our users have large systems, and cannot quickly update their JDK.

The JUnit teams' current plan was to have JUnit 5 require JDK 6. (JUnit 4.x only requires JDK 5). If we are to start to remove the dependency from Hamcrest, we might end up migrating the tests of JUnit itself use hamcrest-junit. It would be great to start that process soon, but we rather not have JUnit 5 require JDK 7.

[marcphilipp]

I've opened #105 regarding the JDK 7 requirement.

[marcphilipp]

Proposal: In addition to what has been released so far, we/you release hamcrest-junit 1.3 which depends on hamcrest-core 1.3. Both artifacts are compiled with target JDK 1.6.

That would not only allow JUnit to keep it's test dependency on hamcrest but in addition would make it possible to use JUnit 5 (which will not depend on Hamcrest anymore) along with hamcrest-junit 1.3 on JDK 6.

Does that make sense?

[npryce]

There is already a hamcrest-junit 1.0.0.0 release that depends on hamcrest 1.3. If that is not compatible with JDK 1.6, I can publish a new release (1.0.0.1) that is.

[npryce]

I've created a 1.x.x.x branch of hamcrest-junit and Travis is building that with Java 1.6. https://travis-ci.org/hamcrest/hamcrest-junit/builds/64050527

I'll publish a 1.0.0.1 release from that branch built with 1.6

[marcphilipp]

Before you release it we should fix hamcrest/hamcrest-junit#5 first, right?

[npryce]

I've released Hamcrest-JUnit 1.0.0.1, which is compiled with JDK 1.6.

I didn't notice your comment. We can publish other releases (1.0.1.0, 2.0.1.0) with the generic error collector.