Add Eclipse JDT embedded lockfiles, upgrade formatter version to 4.40

[scordio]

• Closes Embed p2 lockfiles for Eclipse JDT #1996

This PR introduces lockfiles for the Eclipse JDT formatter, falling back to today's behavior via P2 resolution if an embedded lockfile for the selected version doesn't exist.

In addition, the default JDT version is now upgraded to the latest available (4.40), and embedded lockfiles have been added for versions 4.40, 4.39, 4.11, and 4.9. The rationale for covering the last two is only because those versions appeared in test code, but please let me know what the proper version range should be, and I'll happily adjust this PR and/or introduce missing lockfiles.

To support maintenance and future lockfile generation, I added a new EclipseJdtLockfileMetadataTool among the test classes. This class has two main entry points that can be manually invoked to either verify or update the existing lockfiles by resolving org.eclipse.jdt.core versions directly from the metadata available at https://download.eclipse.org/eclipse/updates/. If you think there is a better approach to achieve the same, please let me know, and I'd be happy to update my changes.

Disclaimer: this is my first Spotless contribution and I wasn't familiar with its codebase and internal architecture. For this reason, I used GitHub Copilot to navigate through it, brainstorm on a possible solution, and implement the self-contained EclipseJdtLockfileMetadataTool class to make lockfile maintenance easier. Nevertheless, I went through and updated pretty much everything that Copilot generated.

---

Please DO NOT FORCE PUSH. Don't worry about messy history, it's easier to do code review if we can tell what happened after the review, and force pushing breaks that.

Please make sure that your PR allows edits from maintainers. Sometimes it's faster for us to just fix something than it is to describe how to fix it.

After creating the PR, please add a commit that adds a bullet-point under the [Unreleased] section of CHANGES.md, plugin-gradle/CHANGES.md, and plugin-maven/CHANGES.md which includes:

• a summary of the change
• either
  • a link to the issue you are resolving (for small changes)
  • a link to the PR you just created (for big changes likely to have discussion)

If your change only affects a build plugin, and not the lib, then you only need to update the plugin-foo/CHANGES.md for that plugin.

If your change affects lib in an end-user-visible way (fixing a bug, updating a version) then you need to update CHANGES.md for both the lib and all build plugins. Users of a build plugin shouldn't have to refer to lib to see changes that affect them.

This makes it easier for the maintainers to quickly release your changes :)

[scordio]

Before creating a pull request, you might want to format (yes, spotless is formatted by spotless) the code and check for possible bugs

./gradlew spotlessApply
./gradlew spotbugsMain

I tried that locally, but it seems I have some cache configuration errors.

Logs

% ./gradlew spotlessApply
Parallel Configuration Cache is an incubating feature.
Calculating task graph as configuration cache cannot be reused because file 'gradle/spotless.gradle' has changed.
Type-safe project accessors is an incubating feature.

6 problems were found storing the configuration cache.
- Task `:lib-extra:spotlessGroovyGradle` of type `com.diffplug.gradle.spotless.SpotlessTaskImpl`: error writing value of type 'com.diffplug.spotless.ConfigurationCacheHackList'
- Task `:lib:spotlessGroovyGradle` of type `com.diffplug.gradle.spotless.SpotlessTaskImpl`: error writing value of type 'com.diffplug.spotless.ConfigurationCacheHackList'
- Task `:plugin-gradle:spotlessGroovyGradle` of type `com.diffplug.gradle.spotless.SpotlessTaskImpl`: error writing value of type 'com.diffplug.spotless.ConfigurationCacheHackList'
- Task `:plugin-maven:spotlessGroovyGradle` of type `com.diffplug.gradle.spotless.SpotlessTaskImpl`: error writing value of type 'com.diffplug.spotless.ConfigurationCacheHackList'
- Task `:spotlessGroovyGradle` of type `com.diffplug.gradle.spotless.SpotlessTaskImpl`: error writing value of type 'com.diffplug.spotless.ConfigurationCacheHackList'
- Task `:testlib:spotlessGroovyGradle` of type `com.diffplug.gradle.spotless.SpotlessTaskImpl`: error writing value of type 'com.diffplug.spotless.ConfigurationCacheHackList'

See the complete report at file:///Users/stefano/Projects/spotless/build/reports/configuration-cache/exlmz05ylu0bpkxw5gri9wjbi/dpcxsijaza6v5jbddk4m3qm4l/configuration-cache-report.html

[Incubating] Problems report is available at: file:///Users/stefano/Projects/spotless/build/reports/problems/problems-report.html

FAILURE: Build failed with an exception.

* What went wrong:
Error while saving task graph
> Configuration cache state could not be cached: field `stepsInternalEquality` of task `:testlib:spotlessGroovyGradle` of type `com.diffplug.gradle.spotless.SpotlessTaskImpl`: error writing value of type 'com.diffplug.spotless.ConfigurationCacheHackList'
   > java.io.IOException: Failed to provision P2 dependencies
> Configuration cache state could not be cached: field `stepsInternalEquality` of task `:lib-extra:spotlessGroovyGradle` of type `com.diffplug.gradle.spotless.SpotlessTaskImpl`: error writing value of type 'com.diffplug.spotless.ConfigurationCacheHackList'
   > java.io.IOException: Failed to provision P2 dependencies
> Configuration cache state could not be cached: field `stepsInternalEquality` of task `:lib:spotlessGroovyGradle` of type `com.diffplug.gradle.spotless.SpotlessTaskImpl`: error writing value of type 'com.diffplug.spotless.ConfigurationCacheHackList'
   > java.io.IOException: Failed to provision P2 dependencies
> Configuration cache state could not be cached: field `stepsInternalEquality` of task `:plugin-maven:spotlessGroovyGradle` of type `com.diffplug.gradle.spotless.SpotlessTaskImpl`: error writing value of type 'com.diffplug.spotless.ConfigurationCacheHackList'
   > java.io.IOException: Failed to provision P2 dependencies
> Configuration cache state could not be cached: field `stepsInternalEquality` of task `:plugin-gradle:spotlessGroovyGradle` of type `com.diffplug.gradle.spotless.SpotlessTaskImpl`: error writing value of type 'com.diffplug.spotless.ConfigurationCacheHackList'
   > java.io.IOException: Failed to provision P2 dependencies
> Configuration cache state could not be cached: field `stepsInternalEquality` of task `:spotlessGroovyGradle` of type `com.diffplug.gradle.spotless.SpotlessTaskImpl`: error writing value of type 'com.diffplug.spotless.ConfigurationCacheHackList'
   > java.io.IOException: Failed to provision P2 dependencies

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Get more help at https://help.gradle.org.

BUILD FAILED in 542ms
Configuration cache entry discarded due to serialization error.

[nedtwigg]

Excellent start! The lockfiles you have right now are keyed in only on the "root" dependency - org.eclipse.jdt.core. The problem is that the transitive dependencies that get resolved will change over time. You'll have a PR that passes CI today, but if you check it out 6 months later, Spotless will complain because it will be resolving a different set of transitive dependencies.

The lockfiles need to set the version of all transitive dependencies, and then the maven configuration needs to be initialized with "downloadTransitives=false" and then explicitly seeded with all the needed transitives and their versions. The reason for this is that Eclipse tends to specify transitives in a wide range, see for examples:

• https://repo1.maven.org/maven2/org/eclipse/jdt/org.eclipse.jdt.core/3.15.0/org.eclipse.jdt.core-3.15.0.pom

<dependency>
<groupId>org.eclipse.platform</groupId>
<artifactId>org.eclipse.core.resources</artifactId>
<version>[3.12.0,4.0.0)</version>
</dependency>

Now, it looks like Eclipse may have changed its policy for recent releases. I just looked at the metadata for 4.40, and I was surprised to see that it specified exact versions rather than broad ranges. So I think there's two options forward:

• A) dig through Eclipse discussions or bisect the actual artifacts to find out when they started specifying exact versions instead of wide ranges, deploy this feature only for those versions
• B) change this feature to do the full explicit transitive thing I outlined above

Doing A is easier. And it has the nice benefit that after A has been merged, you can always go back and do B and then we could turn it on for all versions at any time. Happy to move forward with either.

[scordio]

dig through Eclipse discussions or bisect the actual artifacts to find out when they started specifying exact versions instead of wide ranges

The first version on Maven Central having exact versions seems to be 3.32.0.

I think the discussion about having exact versions happened at:

• Generate pom files with actual versions for deps instead of ranges eclipse-platform/eclipse.platform.releng#128 (comment)

and the change that actually did it is:

• Map osgi.bundle requirement onto a dependency on the resolved version eclipse-platform/eclipse.platform.releng#135

merged in October 2022, before 3.32.0 was published in December.

[scordio]

I tried that locally, but it seems I have some cache configuration errors.

I solved my local issues by pinning the Eclipse version to 4.40 in spotless.gradle:

diff --git a/gradle/spotless.gradle b/gradle/spotless.gradle
--- a/gradle/spotless.gradle
+++ b/gradle/spotless.gradle
@@ -6,8 +6,8 @@
 			ratchetFrom 'origin/main'
 			bumpThisNumberIfACustomStepChanges(1)
 			licenseHeaderFile rootProject.file('gradle/spotless.license')
-			importOrderFile   rootProject.file('gradle/spotless.importorder')
-			eclipse().configFile rootProject.file('gradle/spotless.eclipseformat.xml')
+			importOrderFile rootProject.file('gradle/spotless.importorder')
+			eclipse('4.40').configFile rootProject.file('gradle/spotless.eclipseformat.xml')
 			trimTrailingWhitespace()
 			removeUnusedImports()
 			formatAnnotations()
@@ -17,7 +17,7 @@
 	}
 	groovyGradle {
 		target '*.gradle', 'gradle/*.gradle'
-		greclipse().configFile rootProject.files('gradle/spotless.eclipseformat.xml', 'gradle/spotless.groovyformat.prefs')
+		greclipse('4.40').configFile rootProject.files('gradle/spotless.eclipseformat.xml', 'gradle/spotless.groovyformat.prefs')
 	}
 	format 'dotfiles', {
 		target '.gitignore', '.gitattributes', '.editorconfig'

[scordio]

So I think there's two options forward:

• A) dig through Eclipse discussions or bisect the actual artifacts to find out when they started specifying exact versions instead of wide ranges, deploy this feature only for those versions

• B) change this feature to do the full explicit transitive thing I outlined above

I initially implemented A with 8bb5194, but then spent a bit more time and also implemented B with 71c40eb 🙃

Happy to know what you think!