Support custom jar creation task

[zielu]

Pull Request Details

Name of jar producer task can me customized. Task is still expected to be an instance of Gradle Jar task.

Description

By adding ability to customize name of task that produces plugin jar it is possible to either use customized jar task or some fat jar Gradle plugin (for example Gradle Shadow) to assemble single jar out of multiple modules. By convention default name is set to Gradle JAR_TASK_NAME so existing plugins do not need to change anything on update.

Related Issue

https://github.com/JetBrains/gradle-intellij-plugin/issues/808

Motivation and Context

Support assembly of multi module plugins into single plugin jar.

How Has This Been Tested

With this change I was able to build a single plugin jar out of project that consists of main plugin module and 5 supporting modules.

My project set up is quite specific, let assume I have following modules:

• plugin
• module-api
• module-A
• module-B

module-A and module-B have compileOnly dependency on module-api.

plugin module defines 2 configurations:

• apiPluginModules
• compileOnly.extendsFrom apiPluginModules
• runtimePluginModules

And has following dependencies:

• apiPluginModules on module-api
• runtimePluginModules on module-A and module-B

I'm using Gradle Shadow to create fat jar and it has config like:

shadowJar {
  archiveClassifier.set('')
  configurations = [
      project.configurations.apiPluginModules,
      project.configurations.runtimePluginModules
  ]
}

intellij extension is configured like this:

intellij {
    ...
    jarTaskName = 'shadowJar'
}

Plugin distribution zip was created successfully and I was able to install it and run plugin in a 2022.2 RC Idea.

Types of changes

• [ ] Docs change / refactoring / dependency upgrade
• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• [x] I have read the CONTRIBUTING document.
• [x] My code follows the code style of this project.
• [x] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [x] I have included my change in the CHANGELOG.
• [ ] I have added tests to cover my changes.
• [x] All new and existing tests passed.

[zielu]

I added one more flag - this time prepareSandbox.includeRuntimeConfigurationLibraries. Setting it to false allows creation of truly one-jar deployment - plugin code and all dependencies are bundled into single file.

[zielu]

Hi @Undin, let me share my use case. I have plugin consisting of several modules, one of purposes of modularisation is separating out implementations of APIs that are not compatible between IDE versions - branching in my opinion is a huge hassle to maintain. To load appropriate code version I use service loaders. I also run my plugin through an obfuscator and in order to hide modularisation the best way to do that is combine everything into single jar before obfuscation step.

So what I want from the plugin is combining all modules into a single jar, including service loader definitions and maybe including all external libraries too.

[Undin]

I understood the idea but why do you need to provide a customization here at all? My suggestion is to always merge all jars from all modules in plugin project into single jar. It will solve your problem, common problem with plugin model v2, probably, even improve performance. And I don't see drawbacks of such solution

[zielu]

Well, I'm lazy and wanted to have something working before 2.x arrives (#808 is marked as such). I don't want to solve issues with creating merged jar so decided to create a way to plug in existing solution with as little code as possible.

Thanks for review and comments, I understand that this hacky way is not beneficial to maintain in the plugin. At this time I'm not ready to invest any more time into this topic as I'm happy with working solution I wanted to share here.