Hi, I’m wondering why PluginManagerCore.getPlugin(id: PluginId?) is Internal in IJ 2026.2 EAP. I’m using it since a long time to read the version of my plugin, which is very useful when generating an error report. The commit that added @Internal: [plugins] IJPL-244315 Do not allow plugins to enab…

We know that, but it ultimately requires user attention and approval and may not be allowed to plugins to do silently

[image] Joachim Ansorg: Not doing this would make two providers for the same run configurations available at the same time, which ends up with unpredictable results, bad UX, exceptions and more. I hope we can just introduce a switch-off toggle extension on our side in the Shell Script plugin …

I use this API in my (company-private) plugin to disable the Kubernetes plugin if it’s enabled, because it aggressively claims the file types that my plugin claims, and disabling it programmatically was the easiest way I could find to stop it from happening.

As far as I know we have a simpler way for you to redefine file types using platform APIs, it does not require disabling plugins

Please UNmark those APIs as internal until the “proper” APIs publicly available, it always hard to keep compatibility cross multiple major IntelliJ versions. My cases are: PluginManagerCore.getPlugin(PluginId) for get my plugin’s version. PluginManagerCore.enablePlugin(PluginId) to ask user enabl…

When we introduce such a regulation it does not affect any existing usages, it blocks any new usages though. And when the replacement is available we will ask everyone to migrate.

At the moment we have plans to cover: PluginManagerCore.getPlugin(PluginId) – alternative API without access to ClassLoader PluginManagerCore.getPlugins() – alternative API without access to IdeaPluginDescriptor PluginManagerCore.enablePlugin(PluginId) – suggestion popup/dialog API PluginManagerCo…

[image] izhangzhihao: to ask user enable/install the license plugin @zhihao Please note that you now may safely depend on this plugin in your plugin to require it. It will be installed automatically in Android Studio by dependency and on JetBrains IDEs it is included always

[image] Yuriy Artamonov: When we introduce such a regulation it does not affect any existing usages, it blocks any new usages though. How exactly does that work? When I have a plugin build for 261.* and then publish a build for 262.*, wouldn’t the new upload be blocked because of internal AP…

[image] Joachim Ansorg: wouldn’t the new upload be blocked because of internal API? No, it would not until number of usages changes / new files with errors appear, we will still approve it. You may have noticed Ignored Internal API usages group in your plugin check results

PluginManagerCore.getPlugin is now Internal

IntelliJ Platform

Topic		Replies	Views
2026.2 and now internal PluginManager API IntelliJ Platform api , eap	18	397	July 14, 2026
PluginManager now has all methods as internals IntelliJ Platform	9	225	June 19, 2026
47 internal API usages - how enforced is this requirement? Plugin Verifier	24	322	August 22, 2026
Stricter plugin verification in IntelliJ Platform Gradle Plugin 2.15.0 Announcements plugin-development , intellij-platform-gr	15	414	May 25, 2026
Keeping plugins compatible IntelliJ Platform	0	1214	February 10, 2025

PluginManagerCore.getPlugin is now Internal

Related topics