「JBossEAP7.1からJBossEAP8.0のマイグレーションに挑戦した話①（BOM編）」

Last updated at 2026-06-25Posted at 2026-06-25

第1回：MavenのBOMを導入してわかったメリットと注意点

はじめに

レガシーなJavaプロジェクトの依存関係、
気がつけばカオスになっていませんか？

これまでEclipseでの開発では、
ビルドパスにjarを追加すれば、とりあえず動いていました。

しかし、JavaやJBoss、ライブラリのバージョンアップ対応を進める中で、
これまでIDE側で吸収されていた依存関係を
改めて整理する必要が出てきました。

今回、Eclipseで長年運用していたアプリケーションをMaven化し、
最終的にVSCodeへ移行する取り組みを行いました。

本シリーズでは、
「レガシーなJava開発環境のモダン化」をテーマに、
実体験ベースでまとめていきます。

第1回となる今回は、BOMについてです。

実際に使ってみると便利な反面、つまずきもありました。

この記事では
BOMを採用する中で感じたメリットと注意点を整理します。

【目次】

背景
Maven化の狙い
BOMとは何か
実際に使ってわかったつまずきポイント
学び
まとめ

背景：なぜMaven化が必要だったのか

今回のきっかけは以下のバージョンアップ対応でした。

Java 8 → Java 21
JBoss EAP 7.1 → 8.0

従来利用していたEclipse環境下では
最新のJavaやJBossに対応できなくなることがわかり、
開発環境自体の見直しも必要となりました。

このタイミングで、依存関係の整理に加え、
開発環境をEclipseからVSCodeへ移行することも見据えて、
Maven化を行うことになりました。

Maven化の狙い

Maven化の主な目的は以下です。

依存関係の一元管理
ビルド手順の標準化
環境差異の排除

いわゆる「誰がどこでビルドしても同じ結果になる状態」を目指しました。

BOMとは何か

Maven化を進める中で出てきたのが「BOM（Bill of Materials）」です。

ざっくり言うと、依存ライブラリのバージョンをまとめて管理する仕組みです。

通常の依存関係定義では、それぞれのライブラリに対して
個別にバージョンを指定しますが、

BOMを利用すると、dependencyごとにバージョンを指定せず、
ライブラリ名のみで定義できるようになります。

例）BOMを使わないdependency定義（通常の依存関係定義）

<dependencies>
  <dependency>
    <groupId>jakarta.platform</groupId>
    <artifactId>jakarta.jakartaee-api</artifactId>
    <version>10.0.0</version>
    <scope>provided</scope>
  </dependency>

  <dependency>
    <groupId>org.hibernate.orm</groupId>
    <artifactId>hibernate-core</artifactId>
    <version>6.2.7.Final</version>
  </dependency>
</dependencies>

このようにライブラリごとにversionを書く必要があるため、
依存関係が増えるほど管理が大変になります。

一方、BOMを利用すると、
dependencyManagementタグ内でバージョンをまとめて管理できます。
この状態になると、dependency側では
versionを書かなくても利用できるようになります。

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.jboss.bom</groupId>
      <artifactId>jboss-eap-jakartaee8-with-tools</artifactId>
      <version>8.0.0.GA</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

例）BOM利用後のdependency定義

<dependencies>
  <dependency>
    <groupId>jakarta.platform</groupId>
    <artifactId>jakarta.jakartaee-api</artifactId>
    <scope>provided</scope>
  </dependency>

  <dependency>
    <groupId>org.hibernate.orm</groupId>
    <artifactId>hibernate-core</artifactId>
  </dependency>
</dependencies>

実際に使ってわかったつまずきポイント

1. 外部リポジトリへのアクセス制限

利用するBOMによっては、
Red Hatのリポジトリへアクセスする必要がありました。

そのためRed Hatのアカウントがない状態では、
依存関係の解決ができないケースもあります。

また、アカウントを持っていても、
社内ネットワーク等の制限でSSLエラーやアクセス不可になる場合もあります。
今回の環境下ではセキュリティ上の制約もあり、
アカウントがあっても直接アクセスすることが難しい状況でした。

そのため、Web経由で必要なリポジトリを取得し、
ローカルにサーバーランタイム用のリポジトリを配置して対応しています。

2. BOMの階層構造

BOMが別のBOMを読み込んでいるケースがありました。
この構造になると、

実際にどのバージョンが使われているのか把握しづらい
依存関係の追跡が難しくなる

といった問題があり、理解コストが上がると感じました。

3. バージョン省略には前提条件がある

BOMを利用すると、dependencyにバージョンを書かずに
ライブラリ名だけで定義できるのがメリットです。

ただしこれは、
BOMを正しく参照できる環境があること
が前提になります。

今回、リポジトリアクセスに制約がある環境だったため、
このメリットをそのまま活かせない場面もありました。

学び

BOMは便利な仕組みではあるものの、

利用環境の前提条件はどうなっているか
チームの理解コスト

といった点も含めて判断する必要があると感じました。

また、用途によっては自作のBOMを作成し、
ライブラリ群をまとめて管理するという選択肢もあります。

「便利だから使う」ではなく、
プロジェクトに合うかどうかで判断することが重要だと感じました。

第1回のまとめ

BOMは依存関係管理をシンプルにしてくれる強力な仕組みですが、
その裏にはいくつかの前提条件や運用上の注意点も存在します。

特に今回のように、

Eclipse依存の開発環境
サーバーランタイムへの依存
Java / JBoss のバージョンアップ

といった要素が重なると、
単純なライブラリ管理以上に考えるべき点が増えていきました。

それでも、

依存関係のバージョンを一元管理できる
記述量が減る
バージョンの整合性を保ちやすい

という部分は実際に使ってみて魅力的に感じました。

今回の経験を通して、
依存関係を「なんとなく動いている状態」から
「理解した上で管理する状態」へ変えていく重要性を強く感じました。

おわりに

今回はBOMが既にあるものとした場合を前提にしていましたが、
用途によっては自作のBOMを作成し、
ライブラリ群をまとめて管理するという選択肢もあります。
プロジェクトに合ったベストな方法が見つかりますように。🙏

次回は、実際にEclipseプロジェクトをMaven化していく手順について書いていきます。
最後までお読みいただきありがとうございました。

シリーズ一覧

第1回：BOMを使ってわかったこと（本記事）
第2回：既存javaプロジェクトをMaven化する(手動管理ライブラリ編)
第3回：既存javaプロジェクトをMaven化する(サーバーランタイムライブラリ編)
第4回：VSCodeへ移行する手順と、移行して変わったこと
第5回：レガシーJava開発環境をモダン化して感じたこと

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up