Remove SolrAutoConfiguration from @SpringBootApplication exclusions
#577
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
...gBoot_2_7/java/org/openrewrite/java/spring/boot2/RemoveSolrAutoConfigurationExcludeTest.java
Outdated
Show resolved
Hide resolved
| } | ||
| maybeRemoveImport(SOLR_AUTOCONFIGURATION_FQN); | ||
|
|
||
| return a.withArguments(ListUtils.map(a.getArguments(), it -> { |
There was a problem hiding this comment.
@Laurens-W Notice how I'm unconditionally calling ListUtils.map; that has an optimization in it to not create a new list unless changes are made to the list. That then in turn helps keep our recipe implementation clear of conditionals like the AtomicBoolean you had before, and the if/else checking of values.
| if (newInitializer.isEmpty()) { | ||
| return null; | ||
| } | ||
| return maybeAutoFormat(it, as.withAssignment(array.withInitializer(newInitializer)), ctx); |
There was a problem hiding this comment.
@Laurens-W This quick method allows you to apply the detected style to a code element, such that you need not worry about carrying over a specific space here or there.
|
|
||
| private boolean isSolrAutoConfigurationClassReference(Expression expr) { | ||
| return expr instanceof J.FieldAccess && | ||
| TypeUtils.isAssignableTo(SOLR_AUTOCONFIGURATION_FQN, ((J.FieldAccess) expr).getTarget().getType()); |
There was a problem hiding this comment.
@Laurens-W A pattern I've seen you use a couple times now is to compare with .equals("SomeString"). Try to use TypeUtils where you can for type safe comparisons instead, as that then also handles the FQN case as seen in the added unit test.
| @Nested | ||
| class NoChange { |
There was a problem hiding this comment.
When the number of test cases grows, I like to group them logically for the ones that ought not make any changes. That quickly shows the invariants and makes it logical what to add where.
|
Also: always try to hook your new recipe into a larger upgrade where that makes sense. In this case it's a required upgrade for Spring Boot 3: |
What's changed?
Added recipe to specifically remove the
SolrAutoConfigurationfrom a@SpringBootApplicationexclusions elementWhat's your motivation?
Anything in particular you'd like reviewers to focus on?
Anyone you would like to review specifically?
@timtebeek
Have you considered any alternatives or workarounds?
Any additional context
Checklist