IntelliJのプラグインを作る-Gradle編

2023年12月3日

※ この記事を書いた後にIntelliJ Platform Pluginのメジャーバージョンアップがあり、かなり大幅に変わっているので、もしかしたら参考にならないかもしれない。変更点はJetBrains Plugin Developer Conf 2024を見てもらえるとよいと思う。

前回に続いてWebStormのプラグインを作るまでの道のり第二弾。これまでどうにか避けては通ってきたGradle（グレードル）について。

Androidのアプリ作る時も依存関係の設定やビルドをするのにGradleを使っている。おもにJava、Kotlinのプロジェクトに使われている気がする。

IntelliJのプラグインもJava/Kotlinベースであり、Gradleも使うことになる。全容はGradle IntelliJ Pluginを見てもらうと良いと思う。

今回関係するファイルは大きく分けて4つ。1つずつ見ていこう。

build.gradle.kts

Gradleでどのようなビルドをするのかをbuild.gradle.ktsに書くことになる。前まではGroovyという動的プログラミング言語で書かれていたけど、2023年5月にKotlin DSLがデフォルトになった。

Kotlinは静的型付け言語なので、実行時にエラーがでるのではなくエディタ上でもコンパイル時にもエラーがでる。

IntelliJのプラグインテンプレートには最初から以下のブロックが定義されている。

plugins：ビルドプロセスに追加の機能やタスクを追加するためのプラグインを指定するが、内容は別ファイル（libs.versions.toml）で管理している
repositories：プラグインが格納されているリポジトリを指定する
dependencies：プロジェクトが依存している外部のモジュールを指定する
kotlin：kotlinプラグインの設定でJVMで使用されるKotlinのバージョンとかを指定する
intellij：Gradle IntelliJ Pluginの設定でプラグインの名前とかバージョンを指定するが、内容は別ファイル（gradle.properties）で管理している
changelog：gradle-changelog-pluginの設定で開発しているプラグインのCHANGELOG.mdを自動生成するための情報を指定するが、内容は別ファイル（gradle.properties）で管理している
qodana：Gradle Qodana Pluginの設定を指定する（qodanaについてはまたの機会に…）
- ただしGradle Qodana Pluginはread-only状態になっており、qodana-actionというGitHub Actionsに移行することが推奨されているっぽい
koverReport：Gradle Kover Pluginの設定でKotlinのコードカバレッジを計測するための情報を指定する
tasks：ビルドで何をするかのタスクを1つ1つ指定する

核となるのはtasksで、プラグインごとに書き方が定義されているので、それに沿って書いていく感じになる。

たとえばpublishPluginタスクはGradle IntelliJ Pluginのタスクでドキュメントを見ながら設定していく。

libs.versions.toml

IntelliJのプラグインテンプレートではbuild.gradle.ktsのpluginsは以下のようになっている。

plugins {
    id("java") // Java support
    alias(libs.plugins.kotlin) // Kotlin support
    alias(libs.plugins.gradleIntelliJPlugin) // Gradle IntelliJ Plugin
    alias(libs.plugins.changelog) // Gradle Changelog Plugin
    alias(libs.plugins.qodana) // Gradle Qodana Plugin
    alias(libs.plugins.kover) // Gradle Kover Plugin
}

ビルドに使うプラグインを設定しているのだが、本来はここに以下のようにバージョンを直接書くらしい。

plugins {
    java
    id("org.jetbrains.kotlin.jvm") version "1.9.10"
    id("org.jetbrains.intellij") version "1.16.0"
    id("org.jetbrains.changelog") version "2.2.0"
    id("org.jetbrains.qodana") version "0.1.13"
    id("org.jetbrains.kotlinx.kover") version "0.7.3"
}

それを/gradle/libs.versions.tomlというファイルにまとめて管理してある感じ。

gradle.properties

gradle.propertiesはGradleプロジェクトで使用されるプロパティをまとめて定義しておくファイル。

# プロジェクトのバージョン
projectVersion=1.0.0

# 依存ライブラリのバージョン
libraryVersion=2.3.1

# プロジェクト名
projectName=MyProject

これを用意しておくと、Gradleのビルドスクリプト内から参照できるようになる。

properties("projectVersion")
properties("libraryVersion")
properties("projectName")

settings.gradle.kts

名前の通りだが、Gradleの設定を書く。この辺りで「なんか設定ファイル多いな…」と思い始めたけど「待てよ、フロントエンドでも似たようなものか」と思い直した。

ちなみに現状このファイルに書いているのは以下のみ。

plugins {
    id("org.gradle.toolchains.foojay-resolver-convention") version "0.7.0"
}

rootProject.name = "myProject"

プロジェクトの名前 = プラグインの名前だから、gradle.propertiesと二重管理になっているのが若干気にはなるものの、そんなに頻繁に変更するものでもないし、変更するとしたら作り直すだろうから無視する。

ここで指定されているpluginsはGradleのツールチェーンに関するものらしく「Gradle 8.0 におけるツールチェーンリポジトリの変更」という記事がわかりやすかった。

おまけ「Gradle Wrapper」

今回とは直接関係しないが、プロジェクトで使用するGradleのバージョン自体を管理するためのGradle Wrapperというものがある。

Gradleのバージョンとかが書いてある/gradle/wrapper/gradle-wrapper.propertiesというファイルと、プロジェクトのルートにおいてあるgradlew（おそらくgradle wrapperの略）というスクリプトを使って、Gradle自体を管理するようにしてあるみたい。

ちゃんと調べると仕組み自体はそんなに難しいものではないが、ちゃんと調べることをいつまでも避けて通っていると、簡単なのか難しいのか、それすらも分からない。そんな当たり前のことを気付かされました。

カテゴリ

記事