Update dependency com.github.ekryd.sortpom:sortpom-sorter to v3.2.0

[renovate[bot]]

trafficstars

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
com.github.ekryd.sortpom:sortpom-sorter	3.0.0 -> 3.2.0

---

⚠ Dependency Lookup Warnings ⚠

Warnings were logged while processing this repo. Please check the Dependency Dashboard for more information.

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• [ ] If you want to rebase/retry this PR, click this checkbox.

---

This PR has been generated by Mend Renovate. View repository job log here.

[nedtwigg]

Our SortPomStep hardcodes to version 3.0.0.

https://github.com/diffplug/spotless/blob/27d3ae15dd85fe1a11edfe2950c3cb0c9c0b10f4/lib/src/main/java/com/diffplug/spotless/pom/SortPomStep.java#L45

The underlying artifact (changelog) has a breaking change in 3.1.0, including dropping support for Java 8. If anyone wants to update this, there are two approaches:

1. update sortPomCompileOnly as done in this PR along with L45 noted above to the whatever the latest version is
2. use @davidburstrom's io.github.davidburstrom.version-compatibility plugin to maintain support for multiple versions of sortpom (#1303)

I would be happy to merge either approach. If it was me writing the PR, I would take option 1, it doesn't seem worth it to keep supporting old versions forever.

[davidburstrom]

Maybe I'm missing something here, but bumping that dependency would either require the entire Spotless project to be built with JDK 11, or (probably better), to use Gradle Toolchains to compile the sortPom sourceset or a compat layer against 3.1+.

That would look something like

tasks.named<JavaCompile>("compileCompatSortpom3Dot1Java") {
    javaCompiler.set(
        javaToolchains.compilerFor {
            languageVersion.set(JavaLanguageVersion.of(11))
        }
    )
    options.release.set(8)
}

What do you think?

[nedtwigg]

I don't think the JDK 11 thing is an issue unless there happens to be a JDK 11 class like java.util.concurrent.Flow in the public API, which I don't think is the case. We have lots of formatters which are JDK 11+, all we have to do is gate their tests like so:

https://github.com/diffplug/spotless/blob/0b186ab5217a53bf33f047dc00952cb0889e9121/testlib/src/test/java/com/diffplug/spotless/kotlin/KtfmtStepTest.java#L35-L37

[davidburstrom]

Gated tests are also a requirement, yes. I'm thinking of what's necessary in order to compile against a JDK 11 library, because JDK 1.8 cannot load the classes. Since the Sortpom library also changed its API, it's either necessary to access it through reflection, or by introducing a compat layer (that's compiled with JDK 11, possibly through a toolchain).

[nedtwigg]

I don't think it is true that the compat layer must be compiled with JDK 11. None of our shims are currently compiled with JDK 11, and lots of our libs require 11.

[davidburstrom]

I'll see tomorrow if I can reproduce the error I got when I tried using jdk 8 and the sortpom dependency.

[davidburstrom]

This is the error I get if I simply bump sortpom-sorter to 3.2.0 and compile with JDK 1.8: https://scans.gradle.com/s/nboe7f5nfngb6/console-log?task=:lib:compileSortPomJava#L4

[nedtwigg]

Sorry, I misspoke. You are correct, we do need to compile against JDK 11, and in fact that is what we have done in CI for a long time

https://github.com/diffplug/spotless/blob/de9bb1f757bf2502551cd98dd8f371abf2d1a3fb/.circleci/config.yml#L11

But we can set our compilation target to be Java 1.8, and still compile against artifacts that were compiled against Java 11.

https://github.com/diffplug/spotless/blob/de9bb1f757bf2502551cd98dd8f371abf2d1a3fb/gradle/java-setup.gradle#L9-L10

https://github.com/diffplug/spotless/blob/de9bb1f757bf2502551cd98dd8f371abf2d1a3fb/gradle.properties#L19

This is why I don't believe that the JDK 11 requirement of sortpom 3.2 is an issue for us. It might be an issue for the test_npm_8 CI job, and if it is, I will make it my job to resolve that issue with CI.

[davidburstrom]

Right, this seems correct. Other than using Gradle toolchains, any idea how to fix that for test_npm_8?

[nedtwigg]

One ugly idea is to add an "if" into the build that removes the sortpom sourceset if the build is running on JDK 8. I'm not sure how much longer we'll support JDK 8 anyway (#1337)

[nedtwigg]

I deleted a discussion above related to Java 8 vs 11 complexity which is now resolved since we have updated to Java 11 in #1530. So if anybody wants this version update but was blocked by that, you should be unblocked now.