Take the plugin descriptor from PluginAware, not from PluginManager - #81
Merged
Merged
Conversation
The IntelliJ plugin found its own descriptor through PluginManager.findEnabledPlugin(PluginId), which 2026.2 marks @ApiStatus.Internal, as it does every other way of looking a plugin up by id or by class; the plugin verifier reports the usage against IU-262. The formatting service now implements PluginAware, so the platform hands it the descriptor of the plugin that declares it in plugin.xml, and FormatterProvider.getPluginDescriptor() reaches that service through the formattingService extension point. Both are public API in 2024.2 and in 2026.2. The bundled formatter is still found under <plugin dir>/impl and the settings page still shows the plugin's version. A service the tests create with `new` is given the descriptor of the one the platform created, before the extension point is masked.
CI checks the repository out with fetch-depth 1, so there are no tags and git-version stamps the plugin with a commit hash; FormatterVersion does not parse that, and the test failed there while passing locally. The test now checks what it is for: the settings page has a version to show, taken from the plugin's own descriptor. Also puts the import blocks of the previous commit in the order the repository's formatter keeps, and breaks the long chain as it would.
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
1 participant
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.
The IntelliJ plugin found its own descriptor through
PluginManager.findEnabledPlugin(PluginId). In 2026.2 that method is@ApiStatus.Internal, and so is every other way of looking a plugin up by id or by class (PluginManagerCore.getPlugin,PluginManager.getPluginByClass,getLoadedPlugins,PluginAwareClassLoader); the plugin verifier reports the usage against IU-262.The formatting service now implements
PluginAware: the platform hands it the descriptor of the plugin that declares it in plugin.xml, andFormatterProvider.getPluginDescriptor()reaches that service through theformattingServiceextension point (ExtensionPointName.findExtensionOrFail).PluginAware,PluginDescriptor.getPluginPath()/getVersion()andfindExtensionOrFailcarry noApiStatusannotation in 2024.2.6 or 2026.2.3 (checked in the jars). Behaviour is unchanged: the bundled formatter is still found under<plugin dir>/impl, and the settings page still shows the plugin's version, now pinned by a test.Neither the settings service nor the configurable could take the descriptor directly: the platform injects it only into extension instances it creates from plugin.xml (
XmlExtensionAdapter), not into services, and not into a configurable created throughConfigurableEP. A service the test creates withnewis given the descriptor of the one the platform created, before the extension point is masked.Verification:
./gradlew :open-java-format-idea-plugin:test: 10 tests pass../gradlew :open-java-format-idea-plugin:verifyPlugin, run with the verifier configuration from Publish the IntelliJ plugin to the JetBrains Marketplace on release #80 applied locally (main has none yet; none of it is in this PR): IU-262.10968.63 "Compatible. 1 usage of deprecated API. 2 usages of experimental API", IC-242.26775.15 "Compatible. 2 usages of experimental API".internal-api-usages.txtis gone from the IU report. What remains isTrustedProjects.isTrusted, which stays because its replacement is internal.Once #80 is in, the comment on
failureLevelin build.gradle still namesfindEnabledPluginas the example; the setting itself is unchanged here.