chore: pull Spring Boot 2.7 type changes into a separate recipe

[iuliiasobolevska]

What's changed?

Functionally nothing. Trivial refactoring.

What's your motivation?

I would like to have the possibility to run a recipe for migrating deprecated APIs to the recommended replacements separately from the main org.openrewrite.java.spring.boot2.UpgradeSpringBoot_2_7.

Generally speaking, the more granular OpenRewrite recipes are the most useful they are for our needs (since we cherry-pick only what we need).

Have you considered any alternatives or workarounds?

The alternative is to just invoke org.openrewrite.java.spring.boot2.UpgradeSpringBoot_2_7 but we are already on Spring Boot 2.7 and only have a couple of dozens of usages of deprecated types and nothing else from the recipe seems to apply.

Checklist

• I've used the IntelliJ auto-formatter on affected files

[timtebeek]

Hi @iuliiasobolevska ; thank you for your proposed change here! Something similar came up in #361 previously, so I'd like to understand your use case a bit better before we proceed; hope you don't mind!

We typically recommend users do run UpgradeSpringBoot_2_7 and any downstream recipes that contains repeatedly. That way you pick up any improvements in that recipe chain such as for instance recent fixes in the JUnit 4 to 5 migration, which get's included in the Spring Boot 2.4 migration. All our recipes should not make any changes when run repeatedly, and be relatively fast to run due to preconditions. Any perceived runtime typically is mostly taken up with building the lossless semantic tree. If you experience any issues here we'd love to hear!

While technically splitting up declarative recipes into ever more granular recipes that we compose together is certainly possible, it does run a slight risk of becoming confusing for users browsing the recipe catalog or platform marketplace. Take for instance the list of recipes available for Spring Boot 2, at: https://docs.openrewrite.org/recipes/java/spring/boot2
We already occasionally get reports of users inadvertently running non-composite recipes, or migrating their properties only, when they would most likely have wanted to perform a complete migration instead. Adding a further few "SpringBootTypeChanges_x_y" could then add to that confusion, which is why I'm slightly hesitant & hope you understand.

As an alternative for your use case it's also possible to create a rewrite.yml file, which you can either place in the root of the project that you want to migrate, or package into a rewrite recipe library specific to your company as seen in the rewrite-recipe-starter, that you then pass into the plugins when running, similar to other dependencies. it sounds like you're starting to use OpenRewrite quite a bit over there, given your involvement here, so this might be a good step either way if you hadn't already!

So against that backdrop of concerns and alternatives, could you then let me know if there's anything that would not work for you?

[timtebeek]

I appreciate the suggestion to more flexible in terms of what gets applied, but worry for the usability when users are confronted with multiple choices of per minor Spring version in the docs, as outlined above. I propose we close this PR, at least until we learn more, to clear the backlog a bit. Certainly not meant to discourage or be unappreciative! Hope to see you contribute more. :)