VSCodeへ移行する手順と、移行して変わったこと
はじめに
これまでの回では、Eclipse 上で動いている Java 8 + JBoss EAP 7.1 のプロジェクトを Maven 化してきました。
第4回では、開発環境を VS Code に移行しつつ、
- Java 8 → Java 21
- JBoss EAP 7.1 → JBoss EAP 8.0
というバージョンアップも合わせて行ったときに、何が変わったか/どのように進めたかを整理します。
目次
- 現状と目標、それぞれの制約
- 移行方針の整理
- 事前準備
- 手順1:Java と JBoss のバージョンアップ(Maven 側の準備)
- 手順2:VS Code で新しい環境を開く
- Eclipse から VS Code に移行して感じていること(現時点)
- 第4回:まとめ
- おわりに
現状と目標、それぞれの制約
今回の前提は次のとおりです。
-
現状(移行前)
- Eclipse
- Java 8
- JBoss EAP 7.1
-
ツール側の制約
- Eclipse:JBoss EAP 7.1 までは扱えるが、EAP 8.0 は非対応(VS Code 推奨)
- VS Code:Java 11 以降が前提、JBoss EAP 7.1 は対象外(EAP 8.0 以降を想定)
-
最終的な目標
- 開発環境:VS Code
- Java:21
- JBoss:EAP 8.0
移行方針の整理
この3つ(VS Code / Java / JBoss)は、どれか一つだけを変えても中途半端になってしまうため、
- まず Eclipse + Java 8 + JBoss 7.1 上で Maven 化とサーバーランタイム整理を終わらせる(第1〜3回)
- そのうえで、Java / JBoss のバージョンアップと VS Code への移行を「セット」で行う
という方針を取りました。
IDE・Java・JBoss の対応状況(統合)
| Java | JBoss EAP | Eclipse 対応 | VS Code 対応 | 備考 |
|---|---|---|---|---|
| 8 | 7.1 | ○ | × | 現状の構成。 EAP 7.1 公式の組み合わせ |
| 11 | 7.1 | △(非推奨) | × | EAP 7.1 は Java 8 を前提 |
| 8 | 8.0 | × | △ | Eclipse は EAP 8.0 非対応 |
| 11 | 8.0 | × | ○ | EAP 8.0 の公式サポート対象の一つ |
| 21 | 8.0 | × | ○ | 目標。 |
※ JBoss EAP 7.1 は Java 8 を前提とした構成が公式にサポートされており、
EAP 8.0 は少なくとも Java 11(および多くの場合 Java 17)がサポート対象とされています。
Java 21 + EAP 8.0 の組み合わせについては、記事執筆時点ではバージョンによって状況が変わる可能性があるため、実際に採用する際は Red Hat の最新ドキュメントを確認してください。
事前準備
この回では、次の環境が整っていることを前提に進めます。
- Java 21(JDK 21)がインストール済みで、
java -versionで確認できること - Apache Maven 3.x がインストール済みで、
mvn -versionで確認できること - JBoss EAP 8.0 リポジトリがローカルにあること
- VS Code 本体がインストールされていること
Maven は Eclipse だけで開発していた頃は必須ではありませんでしたが、
VS Code から mvn を利用するために、Apache Maven をローカルにインストールしています。
手順1:Java と JBoss のバージョンアップ(Maven 側の準備)
1-1. pom.xml の Java バージョンを 21 に変更
-
maven-compiler-pluginのsource/targetを 21 に変更する(例)
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<!-- <configuration>
<source>1.8</source>
<target>1.8</target>
</configuration> -->
<configuration>
<source>21</source>
<target>21</target>
</configuration>
</plugin>
一般的には、Java 8 から 21 に上げた際、
- 使っているライブラリが 新しいJava に対応しておらず、コンパイルエラーになる
- 廃止予定 API の使用箇所で警告やエラーが出る
といったケースもありますが、今回のプロジェクトでは、この変更だけで特にコンパイルエラーは発生しませんでした。
1-2. JBoss EAP の BOM を 8.0 系に変更
ここでは、サーバーランタイムのバージョンアップに合わせて、
pom.xml で参照している JBoss EAP の BOM を 7.1 から 8.0 向けのものに差し替えます。
この変更により、EAP 8.0 向けのライブラリセットに切り替わります。
第3回では、EAP 7.1 向けに次のような BOM を定義していました。
次に、サーバーランタイム側のバージョンアップに合わせて、
pom.xml で参照している JBoss EAP の BOM を 7.1 から 8.0 に変更します。
ここを変えることで、EAP 8.0 向けのライブラリセットに切り替わります。
第3回では、EAP 7.1 向けに次のような BOM を定義していました。
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.jboss.bom</groupId>
<artifactId>jboss-eap-javaee7</artifactId>
<version>7.1.0.GA</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
これを、EAP 8.0 向けの BOM に差し替えます(例):
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.jboss.bom</groupId>
<artifactId>jboss-eap-ee</artifactId><!-- 8.0向けのBOMに変更 -->
<version>8.0.0.GA-redhat-00009</version><!-- EAP 8.0に合わせて変更 -->
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
※ 実際に使う artifactId / version は、利用している BOM に合わせて調整してください。
このように BOM を差し替えることで、個々の依存ライブラリの <version> を直接書き換えなくても、
EAP 8.0 が想定しているバージョンの組み合わせに切り替えることができます。
1-3. 環境依存のリポジトリ設定を settings.xml に移す(EAP 8.0 用)
これまでは簡単さ優先のため、pom.xml の <repositories> に
<url>file:///C:/jboss-eap-7.1.0.GA-maven-repository/maven-repository</url>
のように、EAP 7.1 のローカルリポジトリを直接書いていました。
VS Code + Java 11/21 + JBoss EAP 8.0 という新しい構成に移るタイミングで、
- file:///C:/... のような 環境依存のパス
- どのローカルリポジトリを参照するか
といった設定は、プロジェクト (pom.xml) から切り離して、
~/.m2/settings.xml 側にまとめるように整理します。
settings.xml の例(EAP 8.0 用のローカルリポジトリを登録):
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
https://maven.apache.org/xsd/settings-1.0.0.xsd">
<profiles>
<profile>
<id>jboss-eap-local-repo</id>
<repositories>
<repository>
<id>jboss-eap-local</id>
<url>file:///C:/jboss-eap-8.0.0.GA-maven-repository/maven-repository</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>
</profile>
</profiles>
<activeProfiles>
<activeProfile>jboss-eap-local-repo</activeProfile>
</activeProfiles>
</settings>
ポイントは次の2つです。
-
url を EAP 8.0 のローカルリポジトリに向けること
(jboss-eap-8.0.0.GA-maven-repository など、実際のパスに合わせて書き換え) -
環境依存のリポジトリ設定は settings.xml にまとめること
→ pom.xml 側からは、<repositories>の file:///... 設定を徐々に取り除いていけます。
この設定をしておくことで、Maven は BOM や依存ライブラリを解決する際に、
EAP 8.0 用のローカルリポジトリを自動的に参照するようになります。
VS Code も ~/.m2/settings.xml を参照するため、
Eclipse/VS Code/コマンドラインのいずれからビルドしても、同じローカルリポジトリを使えるようになるのがメリットです。
手順2:VS Code で新しい環境を開く
2-1. VS Code と Java 用拡張の準備
まずは VS Code 本体と、Java 開発用の拡張機能をインストールしておきます。
- VS Code 本体
- Extension Pack for Java(Java 開発に必要な拡張一式)
- Maven for Java
- Project Manager for Java
- JBoss ToolKit(JBoss EAP との連携用)
- XML(
pom.xmlなどの編集用)
ざっくりとした流れは次のとおりです。
-
VS Code を公式サイトからインストールする
(https://code.visualstudio.com/download) -
VS Code を起動し、拡張機能ビューから「Extension Pack for Java」をインストールする
-
続けて「Maven for Java」拡張をインストールする
インストール画面や OS ごとの違いなど、より詳しい手順については、
私は次の記事を参考にしました。
また、今回 Maven は個別にインストールしているため、
VS Code から利用する mvn の場所も設定しておきます。
例として、C:\tools\apache-maven-3.9.5\bin\mvn.cmd にインストールした場合は、
VS Code の設定(settings.json)に次のように追記します。
{
"maven.executable.path": "C:\\tools\\apache-maven-3.9.5\\bin\\mvn.cmd"
}
これにより、「Maven for Java」拡張がこの mvn を使ってビルドや依存解決を行うようになります。
2-2. Maven プロジェクトを VS Code で開く
VS Code の準備ができたら、既存の Maven プロジェクトを開きます。
- VS Code で「ファイル」>「フォルダーを開く」を選択。
-
pom.xmlが置いてあるプロジェクトのルートフォルダを選択。 - 初回オープン時は、「このフォルダーを信頼しますか?」といったダイアログが出る場合があるので、「信頼する」を選択。
数秒待つと、右下に「Java プロジェクトを検出しました」などの通知が表示され、
VS Code が自動的に Maven プロジェクトとして認識してくれます。
2-3. 使用する JDK を Java 21 に切り替える
VS Code で使用する JDK が Java 21 になっているかを確認します。
- VS Code のCtrl + Shift + P でコマンドパレットを開き、「Java: Configure Java Runtime」を実行
-
JAVA_HOME/PATHは事前に Java 21 を指すようにしておく - インストール済みの JDK の一覧から、Java 21 を選択
2-4. VS Code から Maven ビルド & デバッグ
VS Code の準備ができたら、実際に Maven ビルドを行い、
JBoss EAP 8.0 へデプロイして動作確認します。
2-4-1. VS Code から Maven ビルドを実行する
- 左側の「JAVA PROJECTS」ビューで、対象プロジェクトを右クリック 。
- 「Maven」>「Run Maven Commands...」を選択。
-
clean→packageの順に実行。
ターミナルビューに Maven のログが流れ、
最後に BUILD SUCCESS が表示されれば、
VS Code から Maven ビルドが通っている状態です。
2-4-2. JBoss ToolKit で JBoss EAP 8.0 にデプロイする
今回は、JBoss ToolKit を使って VS Code から直接 JBoss EAP 8.0 にデプロイしています。
大まかな流れは次のとおりです。
- JBoss ToolKit のビュー(例:「JBoss Servers」や「JBoss EAP」ビュー)を開く。
- 「新しいサーバーを追加」から、ローカルの JBoss EAP 8.0 のインストールディレクトリを指定してサーバーを登録。
- 登録したサーバーに対して、今回の Maven プロジェクト(または生成された WAR)をデプロイ対象として追加。
- 例:サーバーを右クリックして「Add Deployment」を選択し、対象プロジェクトを選ぶ。
- サーバーを「開始」または「再起動」すると、JBoss ToolKit が自動的に WAR をデプロイ。
デプロイが成功すると、例えば次のような状態になります。
- サーバーのコンソールログに
Deployed "xxx.war"のようなメッセージが出力されている - JBoss ToolKit 上のサーバー/デプロイの状態にエラー表示が出ていない
この状態で、
- ブラウザからアプリのコンテキストルートにアクセスして画面が表示される、
または - SoapUI などのツールからリクエストを送り、設定したブレークポイントで処理が停止する
といったことが確認できれば、
VS Code からビルドした WAR が JBoss EAP 8.0 上で正しく動作していると判断できます。
※ 実際のメニュー名やビュー名は、使用している JBoss ToolKit のバージョンによって多少異なります。
ご自身の環境で使っている操作に合わせて読み替えてください。
Eclipse から VS Code に移行して感じていること(現時点)
良かった点
-
Maven /
pom.xmlベースの構成だと IDE をまたいでも再現しやすい
Eclipse でも VS Code でも、pom.xmlを開いてmvnを叩けば同じ依存関係・ビルドが再現できるようになりました。 -
設定が
pom.xmlや各種設定ファイルとして残るようになった
設定を IDE の画面上だけで完結させず、pom.xmlやsettings.xml、VS Code の設定ファイルとして残せるようにしたことで、
どの環境でも同じ手順でビルド・実行しやすくなったと感じています。
まだ実際にチームで共有しているわけではありませんが、将来的に設定をそのまま共有できる土台になりました。
戸惑った点
-
サーバーランタイムの扱いが Eclipse と違う
Eclipse のサーバービューに慣れていたこともあり、最初は
「どこでサーバーを登録して、どのメニューからデプロイするのか」を探すところからのスタートでした。 -
UI でポチポチ設定するより、設定ファイルを編集する場面が増えた
これまでも名前だけは知っていた設定ファイル(pom.xmlやsettings.jsonなど)について、
「どの設定をどこに書くのか」を改めて意識する必要が出てきました。
最初は整理が必要でしたが、そのおかげで今まで何となくしか理解していなかった部分が浮き彫りになり、
きちんと学び直す良い機会になったと感じています。
第4回:まとめ
今回は、「Eclipse + Java 8 + JBoss EAP 7.1」で動いていた Maven プロジェクトをベースに、
- Java のバージョンを 21 に引き上げる
- JBoss EAP の BOM を 7.1 向けから 8.0 向けに差し替える
- 環境依存だったリポジトリ設定を
pom.xmlからsettings.xml側に整理する - VS Code に必要な拡張機能を入れ、Maven ビルド・JBoss ToolKit 経由のデプロイ・デバッグができるようにする
というところまでを一通り進めました。
「開発環境のモダン化」は、単に IDE を Eclipse から VS Code に変えるだけではなく、
Java や JBoss のバージョン、Maven の設定、デプロイ方法までを含めて一貫した構成にそろえる作業だったように思います。
第1〜3回で Maven 化とサーバーランタイムの整理を済ませていたおかげで、
pom.xml や settings.xml を中心に、比較的小さい変更で新しい環境へ移行できました。
おわりに
次回(第5回)は、この一連のモダン化を通じて見えてきたことや、
実際にやってみて感じた教訓を振り返る回としてまとめていきます。
長くなってしまいましたが、どなたかの参考になれば嬉しいです。
最後までお読みいただきありがとうございました。
シリーズ一覧
第1回:BOMを使ってわかったこと
第2回:既存javaプロジェクトをMaven化する(手動管理ライブラリ編)
第3回:既存javaプロジェクトをMaven化する(サーバーランタイムライブラリ編)
第4回:VSCodeへ移行する手順と、移行して変わったこと(本記事)
第5回:レガシーJava開発環境をモダン化して感じたこと