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…

Disabling plugins I think a valid use case to turn off or disable other plugins is, when several provide the same functionality and thus should not be installed at the same time, like file types for the same extensions, run configuration overlap, and more. For example, BashSupport Pro and the Shell…

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…

JetBrains Platform

PluginManagerCore.getPlugin is now Internal

IntelliJ Platform

show post in topic

Home
Categories
Guidelines
Terms of Service
Privacy Policy

Powered by Discourse, best viewed with JavaScript enabled