株式会社ヘンリーでSREなどをやっている戸田（id:eller）です。 私は先日より複数のブログやプレゼンで「Gradleプロジェクトを分割したいけどできてない」と言っております。 Gradleプロジェクト分割にはコードの置き場所が明確になってプログラマの心理的な負担を下げ、Gradleプロジェクトという単位で依存を管理することで不正な依存が入る余地を減らす利点があります。またKotlinコンパイルひいてはGradleビルドの高速化にも繋がるため、プロダクト品質や開発体験を向上するにあたって重要な施策だと考えています。 そして……とうとうやりましたよ！プロジェクト分割を！！！🎉 ということで今回はGradleプロジェクトを分割する際に配慮したことをまとめておきます。 そもそもGradleプロジェクト分割は何が難しいのか Gradleに限らずMavenでもAntでも良いのですが、プロジェク
Gradle v7.5の時点ではまだIncubating段階の機能ではあるのですが、Gradleの新しいプラグイン jvm-test-suite がいい感じなので紹介します。 docs.gradle.org 解きたい課題：サブモジュールや統合テストが出てくるととたんに面倒になるビルドスクリプト Gradleは設定をDSLで記述するので基本的には何でもありなのですが、やはり定形コード（boilerplate）は少ないほうがビルドスクリプトの見通しも良くなります。もちろんGradleは「設定より規約（Convention over Configuration）」の考えを持っているため、ある程度は空気を読んでSourceSetやTaskを自動的に生成してくれます。しかしテスト周りにおいてはこうした自動生成は十分ではなく、次に挙げるような課題がありました： サブプロジェクト全てに対して実行したタス
こちらのエントリーが素敵だなと思ったので、最近書いてるKotlinプロジェクトのベストプラクティスをまとめてみます。一部はJavaプロジェクトにおいても利用できるはずです。 zenn.dev 基本方針 参加障壁を下げる。OSSプロジェクトでもプロプライエタリ・ソフトウェアプロジェクトでも、新しい開発者が参加するコストを下げることには大きな意義がある。 環境差異を吸収する。javaにPATHが通ってさえいればOSに関係なくビルドが通るようにする。 プロジェクト固有ルールを作らない。Conventional CommitsやKeep a changelogなど、ひろく世に使われているルールを採用する。 Gradleを設定する Spotlessを使う コードのフォーマットはformatterに任せて人間は細かいことを考えない、というのが不特定多数が参加するソフトウェアプロジェクトのあるべき姿だと
とある Gradle Plugin を 2.0.0 に移行する際、v1 から Kotlin DSL を使っていた人の環境でちょっと問題が発生したというツイートを見たので、Kotlin DSL がどうやって DSL Marker なしに lambda で書けるようにしてるのかちょっと調べてみた。ここで記述している問題は 2.0.1 では修正されていて、また Kotlin DSL での移行ステップも README に追記しておきました。 github.com TL;DR 外に見せる境界で def を使うのは避けておいた方が無難 Kotlin DSL は拡張関数で delegate してて、見るべきメソッドが違うかもしれないから気をつけよう Kotlin と Gradle の言語仕様の違いに気をつけよう kotlin-dsl を apply して開発しないと Groovy と Kotlin DS
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
