Only add hamcrest-junit dependency when using assertThat or assumeThat

[FieteO]

What's changed?

Remove the hamcrest-junit dependency when running the JUnit4to5Migration recipe.

What's your motivation?

The dependency is not needed in the Junit 5 context (AFAIK)

[timtebeek]

How does this interact with this recipe a little further up/down? As we seem to add that explicitly in a JUnit 5 upgrade

rewrite-testing-frameworks/src/main/resources/META-INF/rewrite/junit5.yml

Line 92 in b7d3b84

- org.openrewrite.java.testing.hamcrest.AddHamcrestIfUsed

rewrite-testing-frameworks/src/main/resources/META-INF/rewrite/junit5.yml

Lines 166 to 172 in b7d3b84

	- org.openrewrite.java.dependencies.AddDependency:
	groupId: org.hamcrest
	artifactId: hamcrest-junit
	version: 2.x
	scope: test
	onlyIfUsing: org.junit.Assume
	acceptTransitive: true

What makes that the dependency is not or no longer needed in your case?

[FieteO]

Hmm, you are right. Probably some more investigation is needed as to when the dependency is needed/when it can be removed.
The hamcrest-junit seems to have been the result of decoupling the Hamcrest portions in Junit 4 into a separate dependency.
This dependency hasn't received an update since 9 years and it's hard to say what use it serves. The PR that added it to the junit5.yml was titled Migrate JUnit 4 Assume#assumeThat()tohamcrest-junit`` to fix issue #327 .

As far as I can tell, Junit 5 also has support for Assumptions.
Maybe @knutwannheden can comment on this?

[timtebeek]

This was a fun one @FieteO ; thanks for raising this for visibility. Turns out we were a little too eager adding that hamcrest-junit dependency on any use of org.junit.Assume, as opposed to only when using assertThat or assumeThat. Solved now by creating a new scanning recipe that looks at methods in use and only if found adds the dependency.

[timtebeek]

Ended up removing the declarative AddDependency that was there before, and implementing a scanning recipe that's a little more selective. Thanks again for calling out this issue with over eager dependency addition!

[FieteO]

Great, that there indeed was something to improve here. Thanks @timtebeek for working on this.