Tim te Beek

hi @nickdala ; thanks for the detailed analysis here! Help accounting for this case would indeed be appreciated. I wonder if this is perhaps best tackled with a separate ScanningRecipes...

hi @williamkmorton ; thanks for pointing this out! Indeed seems like an oversight on the recipe implementation. I'll link the relevant parts here. The declarative recipe that makes the change...

Thanks for the offer to help! We tend to work with forks for outside contributors, and you can open a pull request from there: https://github.com/openrewrite/rewrite-migrate-java/fork

Thanks for making those adjustments! That's indeed been holding back a review because of the time investment needed to adjust the PRs. We'll have another look!

Thanks a lot! We'll merge as soon as the tests pass, and then this should go out with the release ~Wednesday

Thanks for the suggestion @delanym ; I've moved this to rewrite-migrate-java, as that's where we also have other recipes that adopt features added in later Java versions. I see some...

There was earlier work towards this before the lombok recipes moved to this module; pulling that over here could see this resolved rather quickly: - https://github.com/openrewrite/rewrite/pull/3306

I'd implement this as a recipe that takes in an argument, which we then add to the Java 17 and 21 migrations.

As a quick starter; here's how we'd test this type of recipe ```java import org.junit.jupiter.api.Test; import org.openrewrite.DocumentExample; import org.openrewrite.java.JavaParser; import org.openrewrite.test.RewriteTest; import static org.openrewrite.java.Assertions.java; import static org.openrewrite.java.Assertions.javaVersion; class AvoidConflictingImportsTest implements...

Had a quick look at what's necessary here, and updated the tests above already. We likely have to make a change here to fix one of the tests, as we...