【Gradle】JacksonのSNAPSHOTバージョンを利用する

JacksonのSNAPSHOTはSonatype NEXUSのSnapshotリポジトリへアップロードされているため、repositoriesへそれを参照する設定を追加すれば利用できます。
repositoriesは上から評価されるため、この設定をmavenCentralより上に書いてしまうと、依存の解決速度が非常に遅くなる可能性が有る点に注意が必要です。

repositories {
    mavenCentral()
    // mavenCentralより下に書くこと
    maven {
        setUrl("https://oss.sonatype.org/content/repositories/snapshots")
    }
}

Jacksonに限らず、同じリポジトリへアップロードされている依存はこの方法で参照できます。

参考

github.com

github.com

【GitHub Actions】CIのワークフローをsetup-gradleに移行した際のメモ【Gradle】

TL;DR

• gradle利用ならsetup-gradleを用いるのがおすすめ
• setup-gradle利用時はsetup-javaのcache: gradleを消す
• wrapper-validationはsetup-gradleで自動実行されるため明示的な指定は不要

移行後のWF（抜粋）は以下のようになりました（実際にはcontents: write権限も必要ですが省略しています）。

      - name: Checkout
        uses: actions/checkout@v4
      - name: Set up java
        uses: actions/setup-java@v4
        with:
          java-version: 17
          distribution: temurin
      - name: Setup Gradle
        uses: gradle/actions/setup-gradle@v4
        with:
          dependency-graph: generate-and-submit
          dependency-graph-continue-on-failure: false
      - name: Lint
        run: ./gradlew lintKotlin

本文

setup-javaの@v3 -> @v4移行に伴い、諸々新しい記述への移行を試みました。
元のWF（抜粋）は以下のようになっていました。

      - name: Checkout
        uses: actions/checkout@v4
      - name: Set up java
        uses: actions/setup-java@v3
        with:
          java-version: 17
          distribution: temurin
          cache: gradle
      - name: Validate Gradle wrapper
        uses: gradle/actions/wrapper-validation@v3
      - name: Lint
        run: ./gradlew lintKotlin

setup-gradleへの移行理由

キャッシュ周りが効率的な旨がアピールされていること、Dependency Submissionが簡単なことが主な理由でした。

github.com

補足: Dependency Submissionについて

GitHubでは、Dependency Submissionを行うことで、プロジェクトの利用する依存に関する脆弱性を管理することができます。
スキャン結果がリポジトリから見られるのは便利ですし、Dependabotによって自動でセキュリティパッチを受け取ることもできます。

docs.github.com

これはアップロードを伴うため、どこかで↓のようにcontents: write権限を設定する必要があります。

permissions:
  contents: write

github.com

移行に当たっての注意点

cache: gradleは要削除

setup-javaのcache: gradleを使ってしまうと、setup-gradleによるキャッシュが妨げられる場合があるそうです。
公式からも注意喚起が有るため、移行に当たっては削除すべきです。

github.com

wrapper-validationはもう不要

setup-gradleに取り込まれて自動実行されるようになったため、wrapper-validationは不要になっています。

github.com

最終的なdiff

以上をまとめて以下のようになりました。

      - name: Checkout
        uses: actions/checkout@v4
      - name: Set up java
-       uses: actions/setup-java@v3
+       uses: actions/setup-java@v4
        with:
          java-version: 17
          distribution: temurin
-         cache: gradle
-     - name: Validate Gradle wrapper
-       uses: gradle/actions/wrapper-validation@v3
+     - name: Setup Gradle
+       uses: gradle/actions/setup-gradle@v4
+       with:
+         dependency-graph: generate-and-submit
+         dependency-graph-continue-on-failure: false
      - name: Lint
        run: ./gradlew lintKotlin

雑感

ここ数年の動きは見てきましたが、GitHub Actionsでのgradle利用関係はかなり洗練されて使いやすくなったなと感じます。
wrapper-validationが不要になったり、Dependency Submission周りが公式に取り込まれたのは本当に嬉しいですね。
後、gradle-build-action@v2時代は↓のような書き方がちょっと不満だったんですが、今はgradlewを使ったいつもの書き方っぽくなっているのも嬉しいです。

    - name: Setup and execute Gradle 'test' task
      uses: gradle/gradle-build-action@v2
      with:
        arguments: test

WFを長年放置されてる方は是非移行してみて下さい。

【Maven】maven-surefire-pluginはデフォルトだと特定パターンに名前が合致するクラスのテストしか実行しない

TL;DR

• maven-surefire-pluginはデフォルトだと特定の命名規則に合致するテストクラスしか実行しない
• 実行されないテストについては、クラス名を変えるか、パッケージ単位指定などを行う必要がある

状況

jackson-module-kotlinのメンテ中、verifyコマンドでは一部テストが実行されないことに気付きました。

github.com

調査した所、以下の記述に辿り着きました。
特定パターンに合致しない名前のクラスは、例え@Testアノテーションが付与されたメソッドが有ったとしてもテストされません。

By default, the Surefire Plugin will automatically include all test classes with the following wildcard patterns:

• "**/Test*.java" - includes all of its subdirectories and all Java filenames that start with "Test".
• "**/*Test.java" - includes all of its subdirectories and all Java filenames that end with "Test".
• "**/*Tests.java" - includes all of its subdirectories and all Java filenames that end with "Tests".
• "**/*TestCase.java" - includes all of its subdirectories and all Java filenames that end with "TestCase".

maven.apache.org

対処

量が多かったこともあってパッケージ一括指定にしました。

<includes>
  <include>com.fasterxml.jackson.module.kotlin.**</include>
</includes>

github.com

雑感

CIで実行されてないテストが有ると分かった時は正直ものすごく肝が冷えました。

自分がメンテナになる前の段階からこの状態になっているテストがいくつか有ったようで、そのまま拡充してしまっていました。
また、ローカルだとIntellijの単体実行や、自分で設定を書いて一括実行していたので気付かなかったです。

ただ、ローカルでちゃんと実行してはいたので、2.x系について致命的な状況が生じていなかったのは良かったです（3.x系には問題を出してしまいましたが、、、）。

【Intellij IDEA(Ultimate)】invalid value for 'gpg.format': ''でGitツールが動かない状況への対処

TL;DR

• .gitconfigのgpg.formatが空文字列の状態だと動かなくなるようだった
• 自分の環境だとformat = sshと修正することで直った

状況

Intellijを使っている時、Copy Link to GitHub Repositoryが動かなくなりました。
Gitツールウィンドウを見た所、invalid value for 'gpg.format': '' bad config variable 'gpg.format' in file '${グローバグ.gitconfigへのパス}' at line ...というエラーメッセージが出ており、リモートを読み込めなくなっていました。

その時点の.gitconfigは以下のようになっていました（※抜粋のため全文ではありません）。

[gpg]
        format =
        program = gpg
[gpg "ssh"]
        program =
        allowedSignersFile =

対処

以下のように、format = sshを指定しRefleshすることで直りました。

[gpg]
-       format =
+       format = ssh
        program = gpg

1年のアウトプットを振り返る

6年目もやっていきます。

wrongwrong163377.hatenablog.com

雑感

今年は引越しを始め土日が潰れる系のイベントが多く、やりたい開発があまりできなかった感が強いです。
また、その間にメンテナンス作業等溜めてしまったので、来年もしばらくはその返済に追われそう……。

返済作業は憂鬱ですが、やりたい開発のために頑張りたいですね。

OSS関連

jackson-module-kotlin関係

去年に引き続き、今年も1å¹´é–“jackson-module-kotlinのメンテナとして活動しました。

今年の活動で特に大きかったのは、value classのデシリアライズサポートを正式にリリースしたことです。
jackson-module-kogeraの方では2023年時点で達成していたものですが、ようやくkotlin-moduleの方にも導入できました。
年単位で取り組んできた修正だったので、リリースできたことが嬉しいです。

jackson-module-kotlin全体へのコントリビューションは、特にvalue class周りのテスト追加が大規模だったこともあり、19,000 ++ / 2,000 --程度になりました。

github.com

また、jackson-module-kogeraの方も一応細々とメンテナンスは続けていました。

その他OSSへの貢献

主にKotlinリポジトリへ、value classを含む関数のリフレクション呼び出しに関するテスト追加で貢献しました。
規模は8,000 ++ / 500 --程度でした。
これらはKFunctionの呼び出し改善をやる前提として出していた内容ですが、正直終わりが見えなかったので手を止めてしまっています……（現状確認できてないですが、本来この作業を行うべきだったはずのJetBrains側で残り分の拡充がされてはいなさそうなのは辛い、、、エラー報告のテストが役立ってそうだったのは嬉しいですが）。

その他含む一覧は以下の通りです。

github.com

初めてのGitHub Sponsors受け取り

年末になってまさかのAWSからまとまった金額が飛んできて驚きました。

一瞬詐欺かと思って震えた
ありがとうございます！後いつもお世話になってます！

Thank you @aws for sponsoring me on @github. You can join them at my sponsors profile: https://t.co/cBYg1SjmPN

— wrongwrong (@wrongwrong16337) 2024å¹´12月27æ—¥

Hatena・Qiitaへのブログ投稿やOSS活動を始めて以来、金銭的な見返りが発生したことは無かったので、とても嬉しかったです。
また、jackson-module-kotlinのメンテナンス活動に関するTideliftでの報酬受け取りにお誘い頂いており、これも多少は生活の足しになりそうです。

個人・法人問わずスポンサーは受け付けておりますのでいかがでしょうか？（ダイマ）

github.com

ブログ・外部登壇

時間を取れなかったことがモロに出たせいで、気付いたらブログは30本切っちゃってました。

• Qiita: 8本
• はてな
  • wrongwrongな開発日記: 14本
  • 趣味の話を書くブログ: 5本

登壇に関しても、気付けば1年半以上できていません。
丁度Jackson 3関係の話があるので、どこかで機会を見て登壇するかもです。

ただ、個人的な優先度はどうしてもOSSのコードを弄る方に向いちゃってるので、来年もブログ・外部登壇方面の貢献は伸びないかなーと思っています。

終わりに

今年は突発のアレコレに振り回されてしまう時間が長かったので、来年はもう少し平穏な1年になって欲しいですね。

jackson-module-kotlinのメンテナンスに関しては、去年段階だと関与を減らすとか言っていましたが、幾らかやりたい変更は有るので、その反映だけはやり切りたいと思っています。
後、Jackson 3対応の方に関してもいい感じにしたいと思います。

kotlin-reflectの改善も手を付けられたら嬉しいですが、そこまでは手が回らないかなあ……。

何にせよ、来年もKotlin絡みで頑張っていきたいと思っています。

【Gradleã€‘ãƒ“ãƒ«ãƒ‰ãŒãƒãƒ³ã‚°ã—ã¦äºŒé€²ã‚‚ä¸‰é€²ã‚‚è¡Œã‹ãªã„å ´åˆã€Javaプロセスをkillすれば回復するかも【Kotlin】

TL;DR

Javaを利用していそうなアプリケーション（e.g. IDE）を全て閉じた上で、なお生きているJavaプロセスがある場合、それをkillすれば回復する可能性が有ります。

自分はmac環境にて、アクティビティモニタからプロセスを目grep・終了とすることで対処しました。
トラブルを起こしていたプロセスは% CPUとCPU時間が異常に高くなっていたので分かりやすかったです。

本文

状況

gradleを用いたKotlinプロジェクトのビルドが途中でハングしてしまい、後続タスク（今回はtest）まで辿り着かない状況になりました。
./gradlew clean、./gradlew --stopã‚„pkill -f '.*GradleDaemon.*'、IDEのキャッシュ無効化・再起動、PC本体の再起動等々、色々試しても改善しなかったです。

対処

冒頭に書いた通りです。

PC本体の再起動をやってもダメだった理由がちょっと分かってないですが、高速起動のために何かが温存されちゃってるのかな……。
以前周りが今回と同じような状況となった際も再起動が効かなかったそうなので、再現性は有りそうだと思っています。

JIS Macでキーボード認識がおかしくなり、ログイン画面でパスワードが正常に入力できない状況への対処

TL;DR

自分の環境では、入力ソースにABCを選ぶことで解決できました（英字と出ている場合不具合が起きている）。

また、以前起きた際はUS配列の外部キーボードなら正常入力できました。

自分は試せていませんが、アクセシビリティキーボード（ソフトウェアキーボード）を使うことでも解決できそうです。

状況

JIS（日本語）配列キーボード搭載のMacBook Proで、ログイン画面のパスワード入力時にキーボード認識がおかしくなり、正常な入力ができない状態になりました。
Macのログイン画面では（少なくとも試したバージョンでは）パスワード欄に何が入力されているか知る術が無いため、この状態では正確なパスワード入力ができません。
加えて、認識されるキー配列がUS配列とは何かズレているようで、US配列想定の入力を行ってもログインできませんでした。

たちの悪いことに、この症状が起きると、再起動やシャットダウンからの起動、セーフモード経由の起動といった手順を踏んでもキーボード認識が正常化しませんでした。
外部キーボードを接続することで解決するかと思いましたが、JIS配列のキーボードを繋いでも同じ症状が出ているようでした。

この症状が起きるきっかけ

自分は過去何度かこの症状に遭遇しましたが、Macをシャットダウンしてから外部キーボードの接続を切り、その後起動すると稀に起きるようでした。
ただ、ググっても同じ症状は出てこず、周りでも心当たりの有る方がいらっしゃらなかったので、何らかのおま環現象なのかと思っています（Karabiner-Elementsとかが悪さしている……？）。

対処法

TL;DRに書いた通りです。

終わりに

このトラブルはログイン画面で起きるという点が非常に厄介でした。
ググっても出てくるのがログイン後しかできない対応ばっかりなんですよね……。

切実にログイン画面のパスワード入力は生表示できるようにして欲しいです。
後、同じことが起きた際に焦らないよう、ロック画面には常にアクセシビリティキーボードを出しておくのがいいかもと思っています。

engrmemo.jp