How can I partition the plugin.xml into other xml files?

IntelliJ Platform
1

The plugin.xml is getting very large and disorganized. How can I split it into other modules or partition it into other xml files?

2

Here you go:

<?xml version="1.0" encoding="utf-8"?>
<idea-plugin xmlns:xi="http://www.w3.org/2001/XInclude">
    <xi:include href="plugin-featureX.xml"/>
    <xi:include href="plugin-featureY.xml"/>
    <xi:include href="plugin-featureZ.xml"/>

    <depends optional="true" config-file="plugin-optional-dependencyX.xml">dependencyXId</depends>
    <depends optional="true" config-file="plugin-optional-dependencyY.xml">dependencyYId</depends>
</idea-plugin>

Add the xmlns:xi to the idea-plugin root element, and then you can use xi:include to pull in other plugin*.xml files unconditionally, and of course you can use depends to pull in optional dependencies.

Note that, at least based on my experience, xi:include is only processed for the root plugin.xml, though depends can be added at any level.

Hope that helps!

2 Likes
3

As @illuminatedcloud said there are two ways:

  1. Use depends to declare dependencies (both optional and required), you can read more here:
    Plugin Configuration File | IntelliJ Platform Plugin SDK
  2. Use include directive with from XInclude namespace. I didn’t find better example than the following:
    Combining XML Documents with XInclude | Microsoft Learn

:bulb: Tip: if you dont want to add a new namespace you may use <depends> several time, including all of you files with the same dependency and make them required.

1 Like
4

This is discouraged practice and will be flagged by Plugin Verifier.

1 Like
5

Could you please provide the best practices to partition the plugin.xml into more specific xml files? Thanks.

6

I’m not sure that there’s a single right answer to this, but the most obvious reasons to partition are going to be features and dependencies, and sometimes both come into play (example below).

My plugin supports multiple languages and frameworks (i.e., “features”), and I break support for each language/framework out into its own plugin-<featureName>.xml file that’s included unconditionally by the top-level file. My plugin also extends functionality for a number of optional plugins (i.e., “dependencies”), e.g., JavaScript/TypeScript, CSS, Velocity, Markdown, Copyright, etc., and I include those into the respective files that extend them as optional dependencies.

In some cases, support for a specific framework needs to be able to operate in Community Edition IDEs where there is no first-class support for JavaScript/TypeScript/CSS, but in commercial IDEs where those languages are available, I provide enhanced support for that framework/language combination via language-specific EPs. That results in an include for the framework and then in the included file, an optional dependency for the feature that may or may not be available, e.g.: plugin.xml unconditionally includes plugin-<framework>.xml which optionally includes plugin-<framework>-javascript-lang.xml.

As present, I have 60 plugin*.xml files covering ~30 core features, ~10 optional plugin dependencies (most from JetBrains but a few not), and 7 optional JetBrains IDEs dependencies (IntelliJ IDEA Community and Ultimate Editions, WebStorm, PhpStorm, PyCharm Professional and Community Editions, and RubyMine) since things like new project wizards differ between IntelliJ IDEA and non-IntelliJ IDEA IDEs.

Let me know if that doesn’t help.