ソフトウェアエンジニアリング

gradle initをせずにプロジェクトを作ることも可能です。

前提

• ローカルマシンに、GradleとJDKが入っている（wrapperタスク実行時のみローカルマシンにGradleが必要）
• インターネットに接続している

まず、プロジェクトのためのディレクトリを作成します。

work% mkdir hello
work% cd hello
hello%

• build.gradle.kts

空のbuild.gradle.ktsを作成します。デフォルトのタスクでwrapperが用意されているのでこれを実行します。
gradle wrapperタスクを実行すると、gradleのダウンロードとwrapperスクリプトを生成します。

hello% gradle wrapper
BUILD SUCCESSFUL in 1s
1 actionable task: 1 executed

hello% ls -a         
.            build.gradle.kts    gradlew.bat
..            gradle
.gradle            gradlew

.gradleディレクトリはリポジトリで共有しないので、gitignoreなどに指定しておきます。

build.gradle.kts に必要な定義をしていきます。

• build.gradle.kts

plugins {
    application
}

application {
    mainClass.set("com.torutk.hello.HelloApp")
}

Gradleに applicationプラグインの使用を指定します。applicationプラグインを指定すると、暗黙的に java プラグインと distribution プラグインもプロジェクトに適用されます。

メインクラスを定義します。ソースファイルは、src/main/javaディレクトリの下にパッケージに応じたパスに配置するとの暗黙的な定義が java プラグインにあるので、それに応じて配置します。

hello/
  +- src
    +- main
      +- java
        +- com
          +- torutk
            +- hello
              +- HelloApp.java

package com.torutk.hello;

public class HelloApp {
    public static void main(String[] args) {
        System.out.println("Hello, hand made gradle project.");
    }
}

runタスクを実行します。

hello % gradle run                     

> Task :run
Hello, hand made gradle project.

BUILD SUCCESSFUL in 416ms
2 actionable tasks: 2 executed

runタスクは、Javaソースファイルをコンパイルしてメインクラスを実行します。jarファイルは生成しません。

jarタスクを実行します。

hello% ./gradlew jar

BUILD SUCCESSFUL in 480ms
2 actionable tasks: 1 executed, 1 up-to-date

hello % ls build/libs     
hello.jar

プロジェクト名（Gradleビルド定義のあるディレクトリ名）がjarファイル名として適用されています。

https://github.com/beryx/badass-jlink-plugin

OpenJDKのjlinkコマンドを使って、カスタムJREとアプリケーションのイメージを作成、jpackageコマンドを使ってのOS固有インストーラの作成を簡単に実現するプラグイン。

build.gradle.kts への記述

• pluginsに、jlinkプラグインのIDとバージョンを指定

plugins {
    application
    id("org.beryx.jlink") version "3.0.1" 
}

この記述だけで、デフォルトの設定でカスタムJREが生成されます。
jlinkタスクを実行すると、以下のようにbuildディレクトリ下にカスタムJREのディレクトリ（image）が作られ、アプリケーションの実行に必要なJREとアプリケーションが生成されます。

hello
  +-- build
        +-- image                      [1]
              +-- bin
              |     +-- hello          [2]
              |     +-- hello.bat      [2]
              +-- conf
              +-- include
              +-- legal
              +-- lib
              +-- man
              +-- release

• カスタムJREのディレクトリ名はデフォルトで image
• カスタムJREのアプリケーション起動バッチ・スクリプトファイル名は、プロジェクト名（プロジェクトのディレクトリ）

jlinkZipタスクを実行すると、imageディレクトリをアーカイブしたzipファイル（image.zip）が生成されます。

jlinkのコマンドオプションを build.gradle.kts に記述

カスタムJREのディレクトリ名、ZIPファイル名は次のように指定できます。

version = "1.0.1" 

jlink {
    imageName = "hello-$version" 
}

jlinkのオプションの指定は次です。

jlink {
    imageName = "hello-$version" 
    options = listOf("--strip-debug", "--no-header-files", "--no-man-pages")
    launcher {
        name = "sayhello" 
    }
}

ビルド成果物には、versionに基づくファイル名が付与されます。
そこで、アプリケーションのアップデートをするたびに、build.gradleのバージョンテキストを変更しコミット、さらにリポジトリにタグを打つといった作業が発生して少々面倒です。

Gradleのプラグインに、gitリポジトリのバージョン情報を引いてきてバージョンに適用してくれるものがいくつかありました。

• palantir gradle git versionプラグイン
  https://github.com/palantir/gradle-git-version
• axion-release-plugin
  https://github.com/allegro/axion-release-plugin

palantirは、ローカルのgitリポジトリの状態だけを見て、version名を決定します。
HEADにタグが付いていない場合、最後のタグからのコミット回数とハッシュをversion名に含めます。また、コミット忘れたファイルが存在するとdirtyを付けるなど凝った振る舞いもあります。

axionは、ローカルのgitリポジトリのタグを見て version名を決定します。が、リモートの状態も見に行っている模様。
タグがない場合、v0.1.0 が付いているとみなします。HEADにタグが付いていないと、バージョン名に-SNAPSHOTを付けます。
releaseタスクを実行すると、現在のバージョンを1つインクリメントしたタグをgitに付けます。バージョン番号の前に、vとかrelとか接頭辞が付いていると、それに倣ってタグ名を付けてくれます。
次のバージョンをインクリメントではなく指定したい場合、markNextVersionタスクでバージョンを指定するようです。
このプラグインは、依存ライブラリをたくさんダウンロードしています。

机上調査メモ¶

palantir gradle git version¶

build.gradle.ktsの記述

plugins {
    id("com.palantir.git-version") version "<current version>" 
}

val gitVersion: groovy.lang.Closure<String> by extra
version = gitVersion()

gradleを実行する環境は、git管理下である必要があります。
gradle printVersionタスクを実行すると、そのgit管理に基づくバージョン番号を表示します。

% ./gradlew printVersion

> Task :app:printVersion
3a53e9b.dirty

上述の状況で生成される成果物に付与されるバージョンは次のようになります。

• gitにタグがない場合、プラグイン名とコミットハッシュが付与
  例）app-3a53e9b.dirty.zip

• gitにタグを付けると、（例：git tag v0.1.0）
  例）app-v0.1.0.zip

% ./gradlew printVersion

> Task :app:printVersion
v0.1.0

• git管理下のファイルに変更を加えて、未コミット状態でビルドすると、バージョン名に.dirtyが付きます。

% ./gradlew printVersion                          

> Task :app:printVersion
v0.1.0.dirty

• git管理下に変更をコミットして、タグは付与していないと、最後に付与したタグからの変更がバージョン名に付きます。タグをつけてからのコミット数と現在のコミットハッシュが付きます。
  

  % ./gradlew printVersion          
  
  > Task :app:printVersion
  v0.1.0-1-g13a45d3
  

axion-release-plugin¶

build.gradle.ktsの記述

plugins {
    application
    id("pl.allegro.tech.build.axion-release") version "1.16.1" 
}

version = scmVersion.version

このプラグインを入れると、currentVersionタスクとreleaseタスクが定義されます。

• gitのタグを打っていないローカルリポジトリ

currentVersionタスクを実行

% ./gradlew currentVersion
:
Project version: 0.1.0-SNAPSHOT

releaseタスクを実行

./gradlew release       

> Task :app:verifyRelease
Looking for uncommitted changes.. 
Skipping ahead of remote check
Checking for snapshot versions.. 

> Task :app:release
Creating tag: v0.1.0
Changes made to local repository only

releaseタスク実行すると、gitのローカルリポジトリにタグが打たれます。

% git tag
v0.1.0

currentVersionタスクを実行すると、gitのタグに基づく 0.1.0が得られます。

% ./gradlew currentVersion  
  :
Project version: 0.1.0

生成される成果物も、app-0.1.0.zip のようにversionが適用されます。

• gitでローカルの修正（コミットなし）

currentVersionタスクの結果は、変化なし

• gitでタグの後にコミット

currentVersionタスクの結果は、0.1.1-SNAPSHOT となります。

サーブレットプログラムを作るには、Gradleのwarプラグインを使います。
しかし、gradle initで生成する選択肢に war プロジェクトは存在しません。
次のissueでwebappをinitで生成できるようにするリクエストが上がっていますが、対応は進んでいないようです。
https://github.com/gradle/gradle/issues/2339

IntelliJ IDEA 2023では新規プロジェクト作成の機能で、Jakarta EE Webアプリケーションの生成が可能ですが、GradleのDSLはGroovyのみとなっています。

• IntelliJ IDEAでJakarta EE Web ApplicationプロジェクトをGradle用に作成し、build.gradleをbuild.gradle.ktsに書き換える
• gradle init で、Java Application を種類として指定して生成、その後build.gradle.ktsの書き換え、ソースディレクトリの追加などを行う
• からのGradleプロジェクトを生成し追記していく