Automatic reordering of imports for new PRs

[timo-a]

Continuing our conversation in a now closed issue: FasterXML/jackson-databind#4448 (comment)

I believe I can set up a workflow that reorders imports on new PRs.
There are still some kinks to be worked out, but I can already offer a preview: #1344

Let me know if this is the format that you have in mind with the code style.
(I cannot run a preview on the master branch because it does not build right now) My mistake, here is a PR for master: #1346

I'll update this issue as I make progress with the actual workflow.

[cowtowncoder]

Ok. that PR did produce imports according to the style guide, as far as I could see.

So cautious +1 for this.

[timo-a]

I have set up a workflow on the master branch of my fork: master...timo-a:jackson-core:master
It is based on (or rather copy pasted from) this PR langchain4j/langchain4j#673.
There are two files:

• receive-pr.yml executes an openrewrite recipe that is referenced in a profile of the pom.xml. This workflow will be executed on the forked repository of the PR-author for security considerations.
• comment-pr will then fetch the diff created by the previous workflow and apply suggestions to the PR. These can be accepted (or ignored) by both maintainer and PR-author.

You can see a preview here: timo-a#3.
As you can see there the part responsible for creating the suggestions¹ cannot always create a suggestion. In such a case it points out the line number which is still useful. Suggestions are only created for parts of the code that the PR-author has changed, so PRs will not blow up in terms of changes.

Feel free to try out your own dummy PRs on the 3.0 or master branch of my fork. You can also already merge #1347 which adds the workflow to this repository, or discuss further.

In the future the workflow can be extended to cover more of the code style, such as collapsing imports, requiring an underscore in front of non public fields and indentation. Moreover there are best practices recipes for sonar qube findings and JUnit/AssertJ. But there is no hurry to add more.

---

¹ google code suggester seems to struggle with moving a line somewhere else, i.e. removing a line and adding another line somewhere else. That's how it was in the initial change set, a swap of consecutive lines (current version) works. I guess its main goal is to point out code smells that appear on lines that the user has changed and it gets confused when an entire line that the user has added is to be removed entirely. It seems to work fine when just modifying a part of the line, e.g. adding the public modifier as shown on the PR that I copied it from.