Add sbt-java-formatter-add-opens plugin

[mkurz]

Just take a look at the change README. Call me crazy, but I like that idea.

• Adds alias for the javafmt[Check][All] commands
• Launches a new sbt <javafmt_command> session and adds the required -add-opens flags

From a user perspective, the commands now just work again on Java 17+. No need to set flags.

[mkurz]

So to make the sbt java formatter plugin work out of the box on Java 17+, in your project you just have to change

-addSbtPlugin("com.github.sbt" % "sbt-java-formatter"           % "0.11.1")
+addSbtPlugin("com.github.sbt" % "sbt-java-formatter-add-opens" % "0.11.1")

Magic 🪄

[mkurz]

Tested locally with sbt 1 and sbt2. --server is required for sbt2 otherwise client mode is default and no new server/jvm will be started which of course would not add any flags.

[mkurz]

I will merge that and cut a milestone.
In worst case we can revert it anyway (which I doubt).

[mkurz]

This solution is not really great.
It will not handle dependsOn(Test / javafmt), like in sbt.

  Compile / unmanagedSources / inputFileStamps :=
    (Compile / unmanagedSources / inputFileStamps).dependsOn(Compile / javafmt).value,
  Test / unmanagedSources / inputFileStamps :=
    (Test / unmanagedSources / inputFileStamps).dependsOn(Test / javafmt).value,

I found a better approach and reverted this again in

• Switch formatter to forked google-java-format CLI in dedicated JVM #264

The new implementation fixes the underlying problem in the main plugin by launching google-java-format in its own JVM with the flags it needs, instead of wrapping javafmt commands in a separate sbt session.

That means the workaround is now transparent no matter how javafmt gets invoked, and it also fixes the javafmtOnCompile case that this approach could not solve reliably.