Plugin Compatibility with IntelliJ Platform Products

Declaring Incompatibility with Module

Starting in 2020.2, a plugin can declare incompatibility with an arbitrary module by specifying <incompatible-with> containing module ID in its plugin.xml.

Modules Available in All Products

A core set of modules is available in all products based on the IntelliJ Platform. These modules provide a set of shared functionalities. The following table lists modules that are currently available in all products.

As of this writing, if a plugin: A) is dependent only on one or more of the modules in the table above, and B) declares those module dependencies in plugin.xml, then any product developed by JetBrains based on the IntelliJ Platform will load it.

Modules Specific to Functionality

More specialized functionality is also delivered via modules and plugins in IntelliJ Platform-based products. For example, the com.intellij.modules.python module supports the Python language-specific functionality. If a plugin uses this module's functionality, such as Python-specific inspections and refactoring, it must declare a dependency on this module.

Note that not all products define and declare modules. For example, PhpStorm does not have its own module, but the product itself depends on (and ships with) the PHP language plugin. A plugin project is compatible with PHP functionality if it declares a dependency on this PHP language plugin.

The following table lists (1) modules or built-in plugins that provide specific functionality, and the products currently shipping with them.

Notes about Module and Plugin Dependency:

(1) This table is not exhaustive; other modules are currently available in JetBrains' IntelliJ Platform-based IDEs. To see a list of modules, invoke the code completion feature for the <depends> element contents while editing the plugin.xml file.

(2) The Java language functionality was extracted as a plugin in version 2019.2 of the IntelliJ Platform. This refactoring separated the Java implementation from the other, non-language portions of the platform. Consequently, dependencies on Java functionality are expressed differently in plugin.xml depending on the version of the IntelliJ Platform being targeted:

• Syntax for 2019.2 and later releases:

  • plugin.xml (allowable alternative):

    <depends>com.intellij.java</depends>

  • Gradle build script (required):

    intellij { plugins.set(listOf("com.intellij.java")) }

    intellij { plugins = ['com.intellij.java'] }

• Syntax required for releases prior to 2019.2, allowable in all releases:

  • plugin.xml:

    <depends>com.intellij.modules.java</depends>

(3) The AppCode and CLion code was restructured in version 2020.3. This refactoring extracted some functionalities into specific modules for easier maintainability and reuse between AppCode/CLion and other JetBrains IDEs. Consequently, dependencies on AppCode and CLion functionalities are expressed differently in plugin.xml depending on the version of the AppCode/CLion Platform being targeted:

(4) The com.intellij.modules.go module name is deprecated starting with the 2020.2 release. Use it only if your plugin targets versions older than 2020.2. When targeting versions 2020.2 and newer, use com.intellij.modules.goland. See GoLand Plugin Development section for information about depending on the Go functionalities in IDEs other than GoLand.

Exploring APIs as a Consumer

Exploring the available packages and classes in a plugin or module utilizes features in the IntelliJ IDEA IDE.

If the project is not up-to-date, reimport the Gradle project as a first step. Reimporting the project will automatically update the dependencies.

In the Project Window, select Project View and scroll to the bottom to see External Libraries. Look for the library Gradle:unzipped.com.jetbrains.plugins:foo:, where "foo" matches, or is similar to the contents of the <depends> tags in plugin.xml or the intellij.plugins declaration in the Gradle build script. The image below shows the External Libraries for the example plugin project configuration explained in Configuring Gradle build script and Configuring plugin.xml.

Expand the External Library (as shown) to reveal the JAR files contained in the library. Drill down into the JAR files to expose the packages and (decompiled) classes.

Exploring APIs as an Extender

If a project is dependent on a plugin or module, in some cases, the project can also extend the functionality available from the plugin or module.

To browse the opportunities for an extension, start by placing the cursor on the contents of the <depends> elements in the project's plugin.xml file. Use the Go to Declaration IDE feature to navigate to the plugin.xml file for the plugin on which the project depends.

For example, performing this procedure on the <depends>com.jetbrains.php</depends> declaration in a project's plugin.xml file will navigate to the plugin.xml file for the com.jetbrains.php (PHP) project. A common, but not universal, pattern in the IntelliJ platform is for a plugin (like PHP) to declare <extensionPoints> and then implement each one as <extensions>. Continuing the example, search the PHP plugin's plugin.xml file for:

• <extensionPoints> to find the opportunities for extending the PHP plugin's functionality.

• <extensions defaultExtensionNs="com.jetbrains.php"> to find where the PHP plugin extends functionality. The extension namespace (in this example com.jetbrains.php) will match the <id> defined in the plugin.xml file.