Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://plugins.jetbrains.com/docs/intellij/plugin-extension-points.html below:

Extension Points | IntelliJ Platform Plugin SDK

See Plugin Extensions for using extension points in your plugin.

By defining extension points in your plugin, you can allow other plugins to extend your plugin's functionality. There are two types of extension points:

• Interface extension points allow other plugins to extend your plugins with code. When defining an interface extension point, specify an interface, and other plugins will provide classes implementing that interface. The providing plugin can then invoke methods on this interface. In most cases, the interface can be annotated with @ApiStatus.OverrideOnly (see Override-Only API).

• Bean extension points allow other plugins to extend a plugin with data. Specify the fully qualified name of an extension class, and other plugins will provide data that will be turned into instances of that class.

1. Add an <extensionPoints> section to plugin.xml, if it's not yet present there.

2. Add a child element <extensionPoint>.

3. Specify the extension point name with the name or qualifiedName attribute *.

4. Depending on the extension point type, specify the interface or beanClass attribute *.

5. If required, specify the area attribute *.

See the Example.

* see the Attributes section for <extensionPoint> for details

The plugin that contributes to the extension point will read the specified properties from the plugin.xml file.

If extension implementations are filtered according to dumb mode, the base class should be marked with PossiblyDumbAware to highlight this. Use DumbService.getDumbAwareExtensions() to retrieve dumb-aware implementations.

Base classes for extensions requiring a key:

• LanguageExtension

• FileTypeExtension

• ClassExtension

• KeyedExtensionCollector

See the Bundling Plugin API Sources section explaining how to expose extension points sources to other plugins.

Consider example extension points declarations:

myPlugin/META-INF/plugin.xml

<idea-plugin> <id>my.plugin</id> <extensionPoints> <extensionPoint name="myExtensionPoint1" interface="com.example.MyInterface"/> <extensionPoint name="myExtensionPoint2" beanClass="com.example.MyBeanClass"/> </extensionPoints> </idea-plugin>

The com.example.MyBeanClass bean class used in the above plugin.xml file is implemented as follows:

myPlugin/src/com/myplugin/MyBeanClass.java

public final class MyBeanClass extends AbstractExtensionPointBean { @Attribute("key") public String key; @Attribute("implementationClass") public String implementationClass; public String getKey() { return key; } public String getClass() { return implementationClass; } }

See Extension properties code insight on how to provide smart completion/validation.

For the above extension points, their usage in anotherPlugin would look like this (see also Declaring Extensions):

anotherPlugin/META-INF/plugin.xml

<idea-plugin> <id>another.plugin</id> <!-- Declare dependency on plugin defining extension point: --> <depends>my.plugin</depends> <!-- Use "my.plugin" namespace: --> <extensions defaultExtensionNs="my.plugin"> <myExtensionPoint1 key="someKey" implementationClass="com.example.MyImplementation"/> <myExtensionPoint2 implementation="another.MyInterfaceImpl"/> </extension> </idea-plugin>

To refer to all registered extension instances at runtime, declare an ExtensionPointName with private visibility passing in the fully qualified name matching its declaration in plugin.xml. If needed, provide a public method to query registered extensions (Sample: TestSourcesFilter.isTestSources()).

myPlugin/src/com/myplugin/MyExtensionUsingService.java

@Service public final class MyExtensionUsingService { private static final ExtensionPointName<MyBeanClass> EP_NAME = ExtensionPointName.create("my.plugin.myExtensionPoint1"); public void useRegisteredExtensions() { for (MyBeanClass extension : EP_NAME.getExtensionList()) { String key = extension.getKey(); String clazz = extension.getClass(); // ... } } }

A gutter icon for the ExtensionPointName declaration allows navigating to the corresponding <extensionPoint> declaration in plugin.xml. Code insight is available for the extension point name String literal (2022.3).

When processing extension implementations or registrations, there might be errors, compatibility and configuration issues. Use PluginException to log and correctly attribute the causing plugin for builtin error reporting.

To report use of a deprecated API, use PluginException.reportDeprecatedUsage() methods.

Examples:

• CompositeFoldingBuilder.assertSameFile()

• InspectionProfileEntry.getDisplayName()

To support Dynamic Plugins, an extension point must adhere to specific usage rules:

• extensions are enumerated on every use, and extension instances are not stored anywhere

• alternatively, an ExtensionPointListener can perform any necessary updates of data structures (register via ExtensionPointName.addExtensionPointListener())

Extension points matching these conditions can then be marked as dynamic by adding dynamic="true" in their declaration:

<extensionPoints> <extensionPoint name="myDynamicExtensionPoint" beanClass="com.example.MyBeanClass" dynamic="true"/> </extensionPoints>

All non-dynamic extension points are highlighted via Plugin DevKit | Plugin descriptor | Plugin.xml dynamic plugin verification inspection.

25 March 2025

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4