Add Eclipse JDT embedded lockfiles, upgrade formatter version to 4.40#3000
Open
scordio wants to merge 2 commits into
Open
Add Eclipse JDT embedded lockfiles, upgrade formatter version to 4.40#3000scordio wants to merge 2 commits into
scordio wants to merge 2 commits into
Conversation
Author
I tried that locally, but it seems I have some cache configuration errors. Logs |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
EclipseJdtLockfileMetadataToolamong the test classes. This class has twomainentry points that can be manually invoked to either verify or update the existing lockfiles by resolvingorg.eclipse.jdt.coreversions directly from the metadata available athttps://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
EclipseJdtLockfileMetadataToolclass 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:If your change only affects a build plugin, and not the lib, then you only need to update the
plugin-foo/CHANGES.mdfor 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.mdfor 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 :)