2020-12-29 時点で私がどうやっているかって言うの。
色々やり方あるし、他でも書いた記憶あるけど、現時点のスナップショットを書いておきます。
必要なもの
以下が実行できること
やること
curl -O https://start.spring.io/build.gradle gradle wrapper idea .
こんだけ。以下は解説とかおまけとか。
やってること
curl で叩いてるのは Spring Initializr です。
SpringBootの雛形を作成してくれるWebサービス。必要なライブラリとかを -d dependencies=web,actuator とかで指定できるんだけど、それはあまり使わなかったり。
build.gradleの最終形までSpring Initializrでできるわけではないし、ここでコマンドで入力するより build.gradle を後で直接編集するほうが早いし、まぁ色々。
用途が限定的なデモの手順やWebUIでやるなら選んでいいと思います。
普通（？）に使うとプロジェクトの一式が入ったzipファイルを作ってくれるんだけど、私が欲しいのは build.gradle だけなので、パスで指定してます。正直このくらいは自分で書いてもいいし、前はそうしてたけど、SpringBootの最新バージョンいくつだっけーとか確認するのも面倒になったし、そこそこいい感じ（例えば SpringBoot2.3.xだと SpringBoot2.2でJUnit5がデフォルトになったのでbuild.gradleを書き換える で書いたようなspring-boot-testからjunit-vintageのexcludeをやってくれる。2.4で要らなくなったけど。）のbuild.gradleにしてくれるので使ってます。
次にGradle Wrapperの生成。ローカルにインストールしているバージョンのGradleで作ります。
Spring Initializrからダウンロードしたらgradlewが入ってるんだけど、バージョンの更新がワンテンポ遅れたりとか、SpringにGradleのバージョンが依存するのは私的に依存が逆なので、コントロールできる手元のGradleでやってます。
バージョンズレでSpring Initializrの作ってくれるbuild.gradleが読めないとかだと使えないのだけど、Gradleも後方互換かなり強いので大丈夫かなって。
Spring Initializrからダウンロードしようと思ったらzipダウンロードからの展開になるし、入ってるののバージョン確認しなきゃだし、まぁ色々。用途が限定的なデモの手順や（以下略
最後にIDEAを起動して、IDEAにGradleを使ってjarのダウンロードとか、プロジェクトの準備をしてもらいます。
そのあとやること
IDEAが起動したら @SpringBootApplication なメインクラスを作ります。
これもSpring Initializrが作ってくれるのとほぼ同じになりますが、コーディングの肩慣らし的な意味もあります。
IDEが元気に動いてるのかとか、メインクラスの名前をどうするのかとか、パッケージをどうするのかとか。この辺りもSpring Initializrで指定して生成できますが、コマンドラインとかWebUIとかで入力する気にはならないんだ。用途が限定的な（以下略
作ったらとりあえず起動。動くかの確認は確実に動くと確信しているところで行います。 このタイミングで「なぜか起動できない」とかも稀によく起こります。JDKいろんなバージョン入れてるもんだから、たまにIDEAが使うのを消しちゃってたり。起こったことがない人は、運がいいか、きっちりしてるか。私の適当さはこれくらいです。
起動したら @SpringBootTest なテストクラスと空っぽの @Test メソッドを作ります。
Spring Initializrで生成できるのと一緒。まぁメインクラスからテストクラスをIDEAに作ってアノテーションつけるくらいなんで、3秒くらいです。
これは他のテストが動き次第、消したり消さなかったり。この手のテストを自動生成すると消せなくなりがちなので、何のためのテストかを認識しながら作るのがいいと思ってます。
やったりやらなかったり、だいたいやること
Spring Initializrで生成するbuild.gradleはGradleプラグインの io.spring.dependency-management で依存ライブラリのバージョンを制御しています。
これをGradle5.2以降で使える platform を使うように変更します。
そのままでも害はないのですが、SpringBoot以外のBOMを使うこともあります。そう言う時に複数の制御方法があるのは避けたいところ。
混在したことによる問題に遭遇したことはないんですが、もし遭遇したらすっごい面倒なことになると思うんですよね……。
意図しないバージョンのライブラリが入った時に解析する方法は少ないほうがいいと思っています。
build.gradle の片付けを終えたら、必要に応じて依存関係を足していきます。
この辺は追加したいライブラリの公式サイトを見たり見なかったりしたあと、なんだかんだでMaven Centralを検索してます。
こんな感じ。
