Migrate HttpComponentsClientHttpRequestFactory.setReadTimeout to SocketConfig.setSoTimeout

[Laurens-W]

What's changed?

Added a conservative recipe to migrate from HttpComponentsClientHttpRequestFactory.setReadTimeout to SocketConfig.setSoTimeout.

What's your motivation?

• Fixes HttpComponentsClientHttpRequestFactory.setReadTimeout was removed in Spring 6.1.0 #540

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

Test coverage

Anyone you would like to review specifically?

@timtebeek

Have you considered any alternatives or workarounds?

Any additional context

For now the recipe assumes a PoolingHttpClientConnectionManager is defined within the same class as the HttpComponentsClientHttpRequestFactory. It doesn't take into account that a PoolingHttpClientConnectionManagerBuilder exists nor does it refactor to this.

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

[timtebeek]

So a thing to note here is that these classpath resources end up in the packaged jar we send out to folks ; right now we're adding four jars, together weighing in at 2.8 MB; there's also alternatives that do not require any addition to the classpath for tests:

rewrite-spring/src/test/java/org/openrewrite/java/spring/test/SpringRulesToJUnitExtensionTest.java

Line 34 in 729164f

.dependsOn("package org.junit; public @interface ClassRule {}", "package org.junit; public @interface Rule {}")

Let's strive to be conservative into what we add as jars, and how we add those. Preferably in src/test when we can, and automatically through parserClasspath entries and the ./gradlew downloadRecipeDependencies task, as opposed to manually.