Correcting MockWebServer migration for OkHttp

[steve-aom-elliott]

What's changed?

• New artifactId corrected from mockwebserver3-junit5 to mockwebserver3
• In-progress work for changing how some classes are built / manipulated. Previously there were many methods existing on MockResponse. Now everything has to be switched to using MockResponse.Builder to change all these values.

What's your motivation?

Compilation failures after previous setup's migration ran.

Anything in particular you'd like reviewers to focus on?

• Trying to see if I can cut down on additional recipe calls given there are a fair number of methods yet to migrate.

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've used the IntelliJ IDEA auto-formatter on affected files

[github-actions]

Suggested change

	import static org.openrewrite.java.Assertions.*;
	import static org.openrewrite.java.Assertions.java;
	import static org.openrewrite.java.Assertions.mavenProject;

[github-actions]

Suggested change

	// TODO: methods receiving MockResponse - maybe add comment instructing to double check?
	// @Test
	// void wip() {
	// rewriteRun(
	// //language=java
	// java(
	// """
	// import okhttp3.Headers;
	// import okhttp3.mockwebserver.MockResponse;
	//
	// class A {
	// void someMethod() {
	// Headers headers = new Headers.Builder().build();
	// MockResponse a = new MockResponse();
	// // .status(String): void
	// // .getStatus(): String
	// // --
	// // .setStatus(String): MockResponse[this]
	// // ---
	// // .headers(Headers): void
	// // .setHeaders(Headers): MockResponse
	// // .getHeaders(): Headers
	// // ---
	// // .addHeader(String): MockResponse
	// // .addHeader(String,Object): MockResponse
	// // .addHeaderLenient(String,Object): MockResponse
	// // ---
	// // .setHeader(String,Object): MockResponse
	// // .removeHeader(String): MockResponse
	// // .clearHeaders(): MockResponse
	// a.header
	// a.trailers(headers);
	// }
	// }
	// """
	// )
	// );
	// }
	@DocumentExample
	@Test
	void shouldUpgradeMavenDependency() {
	rewriteRun(
	spec -> spec.recipeFromResource("/META-INF/rewrite/junit5.yml", "org.openrewrite.java.testing.junit5.UpgradeOkHttpMockWebServer"),
	mavenProject("project",
	// TODO: handle solely J.NewClass and update declarative recipe to include new one.
	//language=xml
	pomXml(
	"""
	<project>
	<modelVersion>4.0.0</modelVersion>
	<groupId>com.example</groupId>
	<artifactId>demo</artifactId>
	<version>0.0.1-SNAPSHOT</version>
	<dependencies>
	<dependency>
	<groupId>com.squareup.okhttp3</groupId>
	<artifactId>mockwebserver</artifactId>
	<version>4.10.0</version>
	<scope>test</scope>
	</dependency>
	</dependencies>
	</project>
	""",
	spec -> spec.after(pom ->
	assertThat(pom)
	.doesNotContain("<artifactId>mockwebserver</artifactId>")
	.contains("<artifactId>mockwebserver3</artifactId>")
	.containsPattern("<version>5\\.(.*)</version>")
	.actual()
	)
	)
	)
	);
	}
	// TODO: methods receiving MockResponse - maybe add comment instructing to double check?

[steve-aom-elliott]

I'm going to try to look into whether I can set up a single visitor to perform all the type changes needed prior to using the JavaTemplate to write the .build() chaining in, as the problem I'm hitting here is that I'm changing MockResponse fields to MockResponse.Builder fields, return types from some of the methods of MockResponse to be on MockResponse.Builder instead, followed by introducing a .build() call that belongs to MockResponse.Builder but returns MockResponse, meaning ChangeType recipe effectively breaks the type attribution, but covers a lot of the scenarios otherwise that I'd want to be changing. Going to probably roll my own visitor that combines functionality from some of the other ones, or create a visitor that is capable of altering a method invocation's signature's parameter types, which I don't believe we have easily accessible a the moment.