Sample build.gradle files?

IntelliJ Platform Gradle Build Scripts
1

Are there sample build.gradle etc. files available for 2.x? Having access to known good build configs would help a great deal. The documentation would be much clearer if it were based on sample plugins with complete sets of build files covering real-world single and multiple module projects. As it is the documentation feels incomplete and confusing.

2

You’re looking for GitHub - JetBrains/intellij-platform-plugin-template: Template repository for creating plugins for IntelliJ Platform?

3

Thanks Jonathan, but no, I have a large existing plugin that I’m moving to 2.x.

4

You can use the IntelliJ Platform Explorer to search for open-source plugins. There’s also a possibility to filter the build system, like Gradle KTS.

5

I didn’t know about the templates, and that’s helpful to see.

Our team is specifically looking for an example on how to get a plugin working in a multi-project build. Any examples or documentation on this? We have a decent amount of experience with multi-project builds, but creating a plugin with this setup isn’t intuitive to us.

6

What do you mean by multi-project builds? Do you want to simply have a multi-modular plugin?

7

I’m using Gradle speak, which I’ve also seen called a multi-module project (maven). See Multi-Project Build Basics for what we’re working with.

8

Our scrappy devs managed to get this working. In case anyone stumbles across this post here are the problems we encountered and how we got around them:

  1. Do not confuse pluginModule with pluginComposedModule. When declaring subprojects in the root gradle.build(.kts), using pluginModule will cause those subprojects to land in a modules folder instead of the jar. There’s clearly a use for that, but it’s not our use. See Multi Module Setup. Read more carefully is the lesson here :man_shrugging:.
    1. Side note, using runtimeOnly instead of implementation works as you’d expect.
  2. You have to have a plugin.xml file in the root project, but you don’t have to declare everything there. We wanted each of our subprojects to declare their own plugin configs.
    1. Don’t use . That’s for another use case that was not ours.
    2. Do use the xmlns namespace in the plugin.xml and then pull in each config file using xi:include. Don’t be a dummy like us and also name those plugin.xml. We opted for the project name to match how we load them in the gradle.build files.
  3. Subprojects need to declare org.jetbrains.intellij.platform.module plugin instead of org.jetbrains.intellij.platform plugin. Only the root gradle.build file should declare org.jetbrains.intellij.platform.
  4. You cannot use intellijPlatform in a subprojects or allprojects block in your root gradle.build project. Don’t be lazy. Use convention plugins instead to declare the dependency on intellijPlatform.
  5. Finally, and this was a real head scratcher, if your using Java’s SPI pattern and a ServiceLoader to load implementations, you have to declare the loader in the ServiceLoader::load method. We stumbled across the solution here in case you’re curious: IJPL-116331. We pass in the loader from the interface class, like MySPIInterface.class.getClassLoader().

Hope this helps someone out there, and do good work!

1 Like
9

We are also going to implement the modular setup option in our wizards and templates

1 Like
10

Please avoid it if possible and use custom extension points supported by the platform instead in plugin modules