> Click the <kbd>Use this template</kbd> button and clone it in IntelliJ IDEA.
12
13
**IntelliJ Platform Plugin Template** is a repository that provides a pure template to make it easier to create a new plugin project (check the [Creating a repository from a template][gh:template] article).
14
15
The main goal of this template is to speed up the setup phase of plugin development for both new and experienced developers by preconfiguring the project scaffold and CI, linking to the proper documentation pages, and keeping everything organized.
-[Continuous integration](#continuous-integration) based on GitHub Actions
41
-[Dependencies management](#dependencies-management) with Dependabot
42
-[Changelog maintenance](#changelog-maintenance) with the Gradle Changelog Plugin
43
-[Release flow](#release-flow) using GitHub Releases
44
-[Plugin signing](#plugin-signing) with Marketplace signing
45
-[Publishing the plugin](#publishing-the-plugin) with the IntelliJ Platform Gradle Plugin
46
-[FAQ](#faq)
47
-[Useful links](#useful-links)
48
49
50
##Getting started
51
52
Before we dive into plugin development and everything related to it, it's worth mentioning the benefits of using GitHub Templates.
53
By creating a new project using the current template, you start with no history or reference to this repository.
54
This allows you to create a new repository easily without copying and pasting previous content, cloning repositories, or clearing the history manually.
55
56
All you have to do is click the <kbd>Use this template</kbd> button (you must be logged in with your GitHub account).
57
58
![Use this template][file:use-this-template.png]
59
60
After using the template to create your blank project, the [Template Cleanup][file:template_cleanup.yml] workflow will be triggered to override or remove any template-specific configurations, such as the plugin name, current changelog, etc.
61
Once this is complete, open the newly created project's _Settings | Actions | General_ page and enable option _Allow GitHub Actions to create and approve pull requests_.
62
63
Now the project is ready to be cloned to your local environment and opened with [IntelliJ IDEA][jb:download-ij].
64
65
The most convenient way for getting your new project from GitHub is the <kbd>Get from VCS</kbd> action available on the Welcome Screen, where you can filter your GitHub repository by its name.
66
67
![Get from Version Control][file:get-from-version-control]
68
69
The next step, after opening your project in IntelliJ IDEA, is to set the proper <kbd>SDK</kbd> to Java in version `21` within the [Project Structure settings][docs:project-structure-settings].
For the last step, review the project metadata in [`gradle.properties`][file:gradle.properties] and [`plugin.xml`][file:plugin.xml], then *optionally* move sources from the generated package to the one that works best for you.
74
Then you can get to work implementing your ideas.
75
76
> [!NOTE]
77
> To use Java in your plugin, create the `/src/main/java` directory.
78
79
80
##Gradle configuration
81
82
The recommended method for plugin development involves using the [Gradle][gradle] setup with the [intellij-platform-gradle-plugin][gh:intellij-platform-gradle-plugin] installed.
83
The IntelliJ Platform Gradle Plugin makes it possible to run the IDE with your plugin and publish your plugin to JetBrains Marketplace.
84
85
> [!NOTE]
86
> Make sure to always upgrade to the latest version of IntelliJ Platform Gradle Plugin.
87
88
A project built using the IntelliJ Platform Plugin Template includes a Gradle configuration already set up.
89
Feel free to read through the [Using Gradle][docs:using-gradle] articles to understand your build better and learn how to customize it.
90
91
The most significant parts of the current configuration are:
92
-Integration with the [intellij-platform-gradle-plugin][gh:intellij-platform-gradle-plugin] for smoother development.
93
- Repository configuration moved to [`settings.gradle.kts`][file:settings.gradle.kts] using the IntelliJ Platform repositories extension.
94
- Configuration written with [Gradle Kotlin DSL][gradle:kotlin-dsl].
95
- Support for Kotlin and Java implementation.
96
- Plugin and dependency versions are declared directly in the Gradle build files.
97
- Integration with the [gradle-changelog-plugin][gh:gradle-changelog-plugin], which automatically patches the change notes based on the `CHANGELOG.md` file.
98
-[Plugin publishing][docs:publishing] through the `publishPlugin` task and GitHub Actions workflows.
99
100
For more details regarding Kotlin integration, please see [Kotlin for Plugin Developers][docs:kotlin] in the IntelliJ Platform Plugin SDK documentation.
101
102
The current target is IntelliJ IDEA 2026.2, with minimum platform build `262` and Java 25 required for compilation and testing.
103
The IntelliJ Platform Gradle Plugin provisions the matching toolchain; Gradle itself can still run on Java 21, as it does in CI.
104
105
###Gradle properties
106
107
The project-specific configuration file [`gradle.properties`][file:gradle.properties] starts with values expected to vary between repositories created from this template:
└── settings.gradle.kts Gradle project settings and repositories
175
```
176
177
In addition to the configuration files, the most crucial part is the `src` directory, which contains our implementation and the manifest for our plugin – [plugin.xml][file:plugin.xml].
178
179
> [!NOTE]
180
> To use Java in your plugin, create the `/src/main/java` directory.
181
182
183
##Plugin configuration file
184
185
The plugin configuration file is a [plugin.xml][file:plugin.xml] file located in the `src/main/resources/META-INF` directory.
186
It provides general information about the plugin, its dependencies, and its extensions.
187
Maintain the plugin description directly in this file, using HTML wrapped in CDATA when needed.
188
189
> [!NOTE]
190
> When using this template for a real plugin, replace the placeholder description with content that describes the final plugin.
You can read more about this file in the [Plugin Configuration File][docs:plugin.xml] section of our documentation.
213
214
215
##Sample code
216
217
The prepared template provides as little code as possible because it is impossible for a general scaffold to fulfill all the specific requirements for all types of plugins (language support, build tools, VCS related tools).
218
Therefore, the template contains only the following files:
└── MyBundle.kt Bundle class providing access to the resources messages
229
```
230
231
These files are located in `src/main/kotlin`.
232
This location indicates the language being used.
233
So if you decide to use Java instead (or in addition to Kotlin), these sources should be located in the `src/main/java` directory.
234
235
> [!TIP]
236
> It is possible to use the [IntelliJ Platform Icons](https://jb.gg/new-ui-icons) in your plugin.
237
238
To start with the actual implementation, you may check our [IntelliJ Platform SDK DevGuide][docs], which contains an introduction to the essential areas of the plugin development together with dedicated tutorials.
239
240
> [!WARNING]
241
> Remember to remove all non-needed sample code files with their corresponding registration entries in `plugin.xml`.
242
243
For those who value example codes the most, there are also available [IntelliJ SDK Code Samples][gh:code-samples] and [IntelliJ Platform Explorer][jb:ipe] – a search tool for browsing Extension Points inside existing implementations of open-source IntelliJ Platform plugins.
244
245
##Testing
246
247
[Testing plugins][docs:testing-plugins] is an essential part of the plugin development to make sure that everything works as expected between IDE releases and plugin refactorings.
248
The IntelliJ Platform Plugin Template project ships with functional test examples and leaves UI testing setup to the plugin author.
249
250
###Functional tests
251
252
Most of the IntelliJ Platform codebase tests are model-level, run in a headless environment using an actual IDE instance.
253
The tests usually test a feature as a whole rather than individual functions that comprise its implementation, like in unit tests.
254
255
In `src/test/kotlin`, you will find a basic `MyPluginTest` test that utilizes `BasePlatformTestCase` and runs a few checks against the XML files to indicate an example operation of creating files on the fly or reading them from `src/test/testData/rename` test resources.
256
257
> [!NOTE]
258
> Run your tests using predefined *Run Tests* configuration or by invoking the `./gradlew check` Gradle task.
259
260
###UI tests
261
262
If your plugin provides complex user interfaces, you should consider covering them with tests and the functionality they use.
263
264
The template does not wire UI testing into the Gradle build by default anymore.
265
If you need UI coverage, start with the IntelliJ Platform SDK guides for [Integration Tests][docs:integration-tests] and [Integration Tests: UI Testing][docs:integration-tests-ui], then add your own test source set, Gradle tasks, and CI workflow for the operating systems you support.
266
267
268
##Predefined Run/Debug configurations
269
270
Within the default project structure, there is a `.run` directory provided containing predefined *Run/Debug configurations* that expose corresponding Gradle tasks:
| Run Plugin | Runs [`:runIde`][gh:intellij-platform-gradle-plugin-runIde] IntelliJ Platform Gradle Plugin task. Use the *Debug* icon for plugin debugging. |
277
| Run Tests | Runs [`:check`][gradle:lifecycle-tasks] Gradle task. |
278
| Run Verifications | Runs [`:verifyPlugin`][gh:intellij-platform-gradle-plugin-verifyPlugin] IntelliJ Platform Gradle Plugin task to check the plugin compatibility against the specified IntelliJ IDEs. |
279
280
> [!NOTE]
281
> You can find the logs from the running task in the `idea.log` tab.
Continuous integration depends on [GitHub Actions][gh:actions], a set of workflows that make it possible to automate your testing and release process.
289
Thanks to such automation, you can delegate the testing and verification phases to the Continuous Integration (CI) and instead focus on development (and writing more tests).
290
291
> [!NOTE]
292
> To ensure the "Create Pull Request" step functions correctly in the "Publish Plugin" job, make sure to enable "Read and write permissions" for actions by navigating to `⚙️ Settings > Actions > General > Workflow permissions`.
293
294
295
In the `.github/workflows` directory, you can find definitions for the following GitHub Actions workflows:
296
297
-[Build](.github/workflows/build.yml)
298
- Triggered on `push` and `pull_request` events.
299
- Builds the plugin with the `buildPlugin` Gradle task and uploads the plugin ZIP as a workflow artifact.
300
- Runs the `check` Gradle task in a dedicated test job.
301
- Runs the `verifyPlugin` Gradle task in a dedicated verification job.
302
- Prepares a draft release of the GitHub Releases page for manual verification.
303
-[Release](.github/workflows/release.yml)
304
- Triggered on `prereleased` and `released` events.
305
- Updates `CHANGELOG.md` with the published release notes when a release body is provided.
306
- Signs the plugin with a provided certificate before publishing.
307
- Publishes the plugin to JetBrains Marketplace using the provided `PUBLISH_TOKEN`.
308
- Uploads the built plugin distribution as a GitHub release asset.
309
- Creates a pull request with the patched changelog when needed.
- Triggered once on the `push` event when a new template-based repository has been created.
312
- Overrides the scaffold with files from the `.github/template-cleanup` directory.
313
- Overrides JetBrains-specific sentences or package names with ones specific to the target repository.
314
- Removes redundant files.
315
316
All the workflow files include inline documentation, so it's a good idea to take a look through their sources.
317
318
###Dependencies management
319
320
This template keeps dependency management explicit and local to the Gradle files that use it:
321
-[`settings.gradle.kts`][file:settings.gradle.kts] declares Gradle plugin versions and repositories.
322
-[`build.gradle.kts`][file:build.gradle.kts] declares the target IntelliJ Platform version and project dependencies.
323
-[`gradle.properties`][file:gradle.properties] stores repository-specific metadata shared by the build and CI workflows.
324
325
> [!NOTE]
326
> To add a regular library dependency, declare it directly in the `dependencies { ... }` block:
327
>
328
>```kotlin
329
> dependencies {
330
> implementation("group:artifact:version")
331
> }
332
> ```
333
>
334
> Add IntelliJ Platform plugin or module dependencies through the `intellijPlatform { ... }` dependency extension described in the [IntelliJ Platform Gradle Plugin documentation][gh:intellij-platform-gradle-plugin-docs].
335
336
Keeping the project in good shape and having all the dependencies up to date requires time and effort, but it is possible to automate that process using [Dependabot][gh:dependabot].
337
338
Dependabot is a bot provided by GitHub that checks build configuration files for outdated or insecure dependencies.
339
When an update is available, it creates a new pull request providing [the proper change][gh:dependabot-pr].
When releasing an update, it is essential to let your users know what the new version offers.
351
The best way to do this is to provide release notes.
352
353
The changelog is a curated list that contains information about any new features, fixes, and deprecations.
354
When they're provided, these lists are available in a few different places:
355
-the [CHANGELOG.md](./CHANGELOG.md) file,
356
- the [Releases page][gh:releases],
357
- the *What's new* section of the JetBrains Marketplace Plugin page,
358
- and inside the Plugin Manager's item details.
359
360
There are many methods for handling the project's changelog.
361
The one used in the current template project is the [Keep a Changelog][keep-a-changelog] approach.
362
363
The [Gradle Changelog Plugin][gh:gradle-changelog-plugin] takes care of propagating information provided within the [CHANGELOG.md](./CHANGELOG.md) to the [IntelliJ Platform Gradle Plugin][gh:intellij-platform-gradle-plugin].
364
You only have to take care of writing down the actual changes in proper sections of the `[Unreleased]` section.
365
366
You start with an almost empty changelog:
367
368
```
369
# YourPlugin Changelog
370
371
## [Unreleased]
372
### Added
373
- Initial scaffold created from [IntelliJ Platform Plugin Template](https://github.com/JetBrains/intellij-platform-plugin-template)
374
```
375
376
Now proceed with providing more entries to the `Added` group, or any other one that suits your change the most (see [How do I make a good changelog?][keep-a-changelog-how] for more details).
377
378
When releasing a plugin update, you don't have to care about bumping the `[Unreleased]` header to the upcoming version – it will be handled automatically on the Continuous Integration (CI) after you publish your plugin.
379
GitHub Actions will swap it and provide you with an empty section for the next release so that you can proceed with your development:
380
381
```
382
# YourPlugin Changelog
383
384
## [Unreleased]
385
386
## [0.0.1]
387
### Added
388
- An awesome feature
389
- Initial scaffold created from [IntelliJ Platform Plugin Template](https://github.com/JetBrains/intellij-platform-plugin-template)
390
391
### Fixed
392
- One annoying bug
393
```
394
395
To configure how the Changelog plugin behaves, i.e., to create headers with the release date, see the [Gradle Changelog Plugin][gh:gradle-changelog-plugin] README file.
396
397
###Release flow
398
399
The release process depends on the workflows already described above.
400
When your main branch receives a new pull request or a direct push, the [Build](.github/workflows/build.yml) workflow runs multiple tests on your plugin and prepares a draft release.
401
402
![Release draft][file:draft-release.png]
403
404
The draft release is a working copy of a release, which you can review before publishing.
405
It uses the current plugin version from [`gradle.properties`][file:gradle.properties] as both the title and git tag, for example, `0.0.1`.
406
The changelog is provided automatically using the [gradle-changelog-plugin][gh:gradle-changelog-plugin].
407
The built plugin archive is uploaded as a workflow artifact during the Build run rather than attached to the draft release itself.
408
Every new Build overrides the previous draft to keep your *Releases* page clean.
409
410
When you edit the draft and use the <kbd>Publish release</kbd> button, GitHub will tag your repository with the given version and add a new entry to the Releases tab.
411
Next, it will notify users who are *watching* the repository, triggering the final [Release](.github/workflows/release.yml) workflow.
412
413
###Plugin signing
414
415
Plugin Signing is a mechanism introduced in the 2021.2 release cycle to increase security in [JetBrains Marketplace](https://plugins.jetbrains.com) and all of our IntelliJ-based IDEs.
416
417
JetBrains Marketplace signing is designed to ensure that plugins aren't modified over the course of the publishing and delivery pipeline.
418
419
The current template keeps signing configuration out of `build.gradle.kts` and relies on the standard environment variables consumed by the IntelliJ Platform Gradle Plugin.
420
That allows you to sign and publish your plugin from both the Continuous Integration (CI) and local environments without checking secrets into VCS.
421
422
To find out how to generate signing certificates, check the [Plugin Signing][docs:plugin-signing] section in the IntelliJ Platform Plugin SDK documentation.
423
424
###Publishing the plugin
425
426
> [!TIP]
427
> Make sure to follow all guidelines listed in [Publishing a Plugin][docs:publishing] to follow all recommended and required steps.
428
429
Releasing a plugin to [JetBrains Marketplace](https://plugins.jetbrains.com) is a straightforward operation that uses the `publishPlugin` Gradle task provided by the [intellij-platform-gradle-plugin][gh:intellij-platform-gradle-plugin-docs].
430
In addition, the [Release](.github/workflows/release.yml) workflow automates this process by running the task when a new release appears in the GitHub Releases section.
431
432
> [!NOTE]
433
> If you need custom Marketplace channels or additional publishing options, add explicit publishing configuration to [`build.gradle.kts`][file:build.gradle.kts] as described in the [publishing documentation][docs:publishing].
434
435
The authorization process relies on the `PUBLISH_TOKEN` secret environment variable, specified in the `⚙️ Settings > Secrets and variables > Actions` section of your project repository.
436
437
You can get that token in your JetBrains Marketplace profile dashboard in the [My Tokens][jb:my-tokens] tab.
438
439
> [!WARNING]
440
> Before using the automated deployment process, it is necessary to manually create a new plugin in JetBrains Marketplace to specify options like the license, repository URL, etc.
441
> Please follow the [Publishing a Plugin][docs:publishing] instructions.
442
443
444
##FAQ
445
446
###How to use Java in my project?
447
448
Java language is supported by default along with Kotlin.
449
Initially, the `/src/main/kotlin` directory is available with minimal examples.
450
You can still replace it or add the `/src/main/java` directory to start working with Java language instead.
451
452
###How to disable *tests* or *build* job using the `[skip ci]` commit message?
453
454
Since February 2021, GitHub Actions [has supported the skip CI feature][github-actions-skip-ci].
455
If the message contains one of the following strings: `[skip ci]`, `[ci skip]`, `[no ci]`, `[skip actions]`, or `[actions skip]` – workflows will not be triggered.
456
457
###Why does the draft release no longer contain a built plugin artifact?
458
459
All binaries created by the workflows are still available as workflow artifacts together with failed test reports or Plugin Verifier results.
460
That approach gives more possibilities for testing and debugging pre-releases, for example, in your local environment.