バージョンページの手順2に、更新先の座標とバージョンで組んだ依存定義の例があります。この章は、バージョンの決まり方ごとの書き換え方です。

共通の注意

• 不要な整形・改行・文字コード・依存の並び順を変えない
• 外部のリポジトリを勝手に追加しない
• バージョンページの別々の候補（たとえば同じライブラリの2つの系列）を1つの成果物に混ぜない
• 権限の無い共通 POM・親 POM・社内 BOM を自分の判断で書き換えない。管理者に依頼する

バージョンを直接書いている場合

Maven

<dependency>
  <groupId><groupId></groupId>
  <artifactId><artifactId></artifactId>
  <version><更新先のバージョン></version>
</dependency>

Gradle

implementation("<groupId>:<artifactId>:<更新先のバージョン>")

プロパティで管理している場合

<properties>
  <対象のプロパティ名><更新先のバージョン></対象のプロパティ名>
</properties>

Gradle では gradle.properties の値、またはバージョンカタログ（gradle/libs.versions.toml）の [versions] を書き換えます。同じプロパティを使っている別の成果物のバージョンも一緒に変わる点に注意します（関連モジュールをそろえる意図なら正しい）。

dependencyManagement・BOM・platform で管理している場合

バージョンが親 POM・BOM・Gradle の platform で決まっている場合は、そこを書き換えるか、プロジェクト側でバージョンを上書きします。上書きした場合は、管理元のバージョンと実際のバージョンが食い違うので、理由を記録します。

推移的依存（ほかのライブラリが連れてくる依存）を上書きする場合

対象のライブラリを直接書いておらず、ほかのライブラリ（親）が連れてきている場合は、次の順で検討します。

1. 親のライブラリを更新すると、対象も上がるか確かめる。 上がるなら、親を更新するのが自然です（親のバージョンページも見てください）
2. 親を更新できない場合は、対象のバージョンだけを上書きする
   • Maven：<dependencyManagement> に対象の座標とバージョンを書く
   • Gradle：dependencies { constraints { implementation("<groupId>:<artifactId>:<更新先のバージョン>") } }
3. 上書きしたバージョンで親のライブラリが動くかは、テストで確かめる（親が想定していないバージョンになる）

座標が変わる場合

バージョンページの「依存定義の座標を変える」が「該当」のときは、groupId・artifactId も書き換えます。古い座標の定義は削除し、新旧の座標が両方残らないようにします（同じクラスが2つの JAR に入り、どちらが使われるか分からなくなります）。

スコープ

サーバーが提供する API（Servlet API など）は、Maven では provided、Gradle では compileOnly にして、成果物（WAR）に同梱しません。