Questions on V2 plugin descriptor

I have questions about the V2 plugin descriptor and related topics and would appreciate help.

As far as I understand, a V2 plugin descriptor is needed to implement split mode in a plugin (YouTube and template repo).

I would like to implement support for remote development/split mode, but I’m unsure about the best way to switch to a V2 descriptor.
I know that V2 is not officially recommended yet (anymore), but split mode would provide the best UI/UX experience and I don’t want to spend much time on non-split mode when I have to switch later anyhow.
Preparing a larger code base for split mode is much harder than doing it from the beginning.

  1. Major versions.
    I’m considering supporting 2025.2+.
    Is that a version with relatively stable and complete V2 descriptors?

  2. Package attribute
    2026.1 deprecated the package attribute in <idea-plugin package="...">.
    I assumed that this is the way how earlier versions like 2025.2 detected a V2 descriptor. Are there any recommendations how to support 2025.2 to 2026.1?

  3. Packages in modules.
    With 2026.1, is there still a requirement to keep modules in separate packages? For a class my.plugin.a.b.c, how would the IDE know in which modules it’s located?

  4. Library dependencies in modules
    Assuming a plugin depends on and bundles external library X.jar.
    How can I make X available to modules?
    I found that loading="embedded" makes X available to modules, but that would not work with optional modules.
    Is there perhaps a way to declare a dependency on the libraries or a special module of the plugin, which provides X?

I’d appreciate your thoughts and feedback!
Thank you!

2 Likes

I’m interested in it too, I wish to make my plugin remote friendly.

Also starting from which version this change is supported?

Hi Joachim!

  1. All the features mentioned in this doc about v2 (modular) plugins except required-if-available should work in 2025.2. required-if-available attribute is supported starting with 2025.3.
  2. Actually, it wasn’t necessary to use package attribute even in 2025.2. If you don’t specify it and register content modules in plugin.xml via content tag, they should work.
  3. It isn’t necessary to keep modules in separate packages even in 2025.2. If you don’t specify package attribute, the IDE will assume that the module classes are located in a separate JAR (lib/modules/<module.name>.jar). Recent versions of IntelliJ Platform Gradle Plugin should pack content modules to such JARs automatically.
  4. You can merge content of X.jar into the module JAR, or create a special plugin module which contains an empty module XML descriptor and class-files from X.jar. I don’t think we have a built-in support for such packaging in IntelliJ Platform Gradle Plugin, though, feel free to file an issue about that. You may also create an empty plugin content module, register it with loading=embedded. In that case if X.jar is put directly in lib directory of the plugin, it’ll be included in the classpath of that module. So you can add a dependency on that module to other modules (even optional), and they will be able to use classes from X.jar.
1 Like

I would strongly recommend targeting only the last Major 2025.3 version for remote development work in your plugins, because it changes rapidly and it is really hard to support more Major versions for it.

We also have an intro video that should be helpful

Are paid plugins supported? I remember some YT issues mentioning they were not yet supported in Gateway. I also tried manually a long time ago, and it was not possible to validate user’s license. At least on the backend side.
Is it different with the new architecture?