自分が書いたファイルは、
どこで、動くものになる？

Hello.javaを作った。実行されるのも、このファイル？

EclipseでHelloProjectを作り、sampleというパッケージにHelloクラスを置いたとします。今、あなたが編集しているのは、人が読んで書くためのソースコードです。

HelloProject/
└─ src/
   └─ sample/
      └─ Hello.java

package sample;

public class Hello {
    public static void main(String[] args) {
        System.out.println("Hello World");
    }
}

この文字の並びを、Javaの実行機構が扱う形式に変換します。その作業がコンパイルです。型や文法などを確認し、ここでは Hello.class というファイルを作ります。元の.javaは消えません。

見えていないだけで、出力フォルダーにできている

HelloProject/
├─ src/
│  └─ sample/
│     └─ Hello.java
└─ bin/
   └─ sample/
      └─ Hello.class

覚えること：.javaは材料、.classはコンパイルでできる生成物。

確認資料：Eclipse Java Builder / 出力フォルダーの設定

Run As → Java Application。その後、何が起きている？

EclipseでHello.javaを右クリックし、Run As → Java Applicationを選ぶと、必要なコンパイルを済ませた上でJavaの実行環境を起動します。そこでclassを読み込んで動かす仕組みをJVM（Java仮想マシン）と呼びます。

main は、このJava Applicationの処理を始める入口です。JVMがsample.Helloのmainを起動し、その中のprintlnが文字を出します。実行ボタンを押す人、準備するEclipse、実際にclassを動かすJVMは、それぞれ役が違います。

javac -d bin src/sample/Hello.java
java -cp bin sample.Hello

ここまでの旅：srcの.java → binの.class → JVM → main。

Calculator.add(1, 2)を使いたい。でもCalculatorは自分で書いていない。

別の人が作った便利な処理を、自分のプログラムから呼ぶことがあります。このような再利用する部品をライブラリと呼びます。配布するclassが増えたら、ファイルを一つずつ渡すより、まとめた方が扱いやすくなります。

// sample.Calculatorが使える状態なら
System.out.println(Calculator.add(1, 2));
// 出力：3

calculator.jar
├─ sample/
│  ├─ Calculator.class
│  └─ MathUtil.class
└─ META-INF/
   └─ MANIFEST.MF

コンパイル済みのclassや、処理に使う設定・画像などのリソースをまとめたファイルがJARです。内部にはフォルダーの並びも保存されます。ZIPを基にした形式で、通常は展開せずに利用できます。

JARをどこかに保存しただけで、Javaは見つけてくれる？

パソコン中を勝手に探すわけではありません。必要なclassを「この場所から探して」と教えます。この探す場所の一覧がclasspath（クラスパス）です。classのあるフォルダーやJARファイルなどを指定します。

覚えること：JARは部品をまとめたファイル。classpathは部品を探す場所。

確認資料：JAR File Specification / javaのclass path

Add JARsを押すと、何が変わる？

JARが見つからない状態では、EclipseはCalculatorを知らないのでエラーを出します。プロジェクトのProperties → Java Build Path → LibrariesでJARを追加すると、その中のclassも探す対象になります。

パソコン全体にライブラリを「インストール」する操作ではありません。通常のJava Applicationでは、プロジェクトの情報を基に実行時のclasspathも組み立てられます。ただし実行構成で変更できるため、コンパイルできることと、実行時にも見つかることは別に確認します。

ここまでで、普通のJavaの仕組みが揃いました。
自分のclassと必要なJARを見つけられるようにして、JVMでmainを起動します。

確認資料：Eclipse Java Build Path / Libraries

ブラウザーから呼ばれるServletには、なぜmainがない？

これまでのJava Applicationでは、mainが処理の入口でした。Webアプリでは、起動して待っているTomcatが、ブラウザーからのリクエストに応じて自分の処理を呼びます。その呼び出されるJavaの部品がServletです。

HTTPはブラウザーとサーバーが要求・応答をやり取りするための決まりです。Tomcatは、どのURLをどのServletに担当させるかを知り、Servletの作成・呼び出しなどを管理します。この役割からServletコンテナ／Webコンテナと呼ばれます。

Tomcat自身もJavaのプログラムです。TomcatがServletを管理し、実際のclassの実行はJVMが担います。自分のServletにmainを書かなくてもよいのは、Tomcatという呼び出し役がいるからです。

package com.example;

import java.io.IOException;
import jakarta.servlet.annotation.WebServlet;
import jakarta.servlet.http.HttpServlet;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;

@WebServlet("/hello")
public class HelloServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest request,
                         HttpServletResponse response)
            throws IOException {
        response.setContentType("text/plain; charset=UTF-8");
        response.getWriter().println("Hello from Web!");
    }
}

覚えること：mainから始まる処理と、リクエストを受けて呼ばれる処理は、入口が違う。

HelloServlet.classは、どのフォルダーに置けばよい？

適当な場所に置けば見つかるわけではありません。Webアプリには、Servlet仕様で定められた配置のルールがあります。まずは「Tomcatへ配置する一つのWebアプリ」の完成形を見てください。開発中のプロジェクトとは区別します。

MyWebApp/
├─ index.html                          ← 画面の資材
├─ index.jsp
├─ css/style.css
├─ js/app.js
├─ images/logo.png
└─ WEB-INF/                            ← アプリ内部の領域
   ├─ classes/
   │  └─ com/example/HelloServlet.class
   ├─ lib/
   │  ├─ library-a.jar
   │  └─ library-b.jar
   └─ web.xml                          ← 必要な構成で使う設定

ServletへのURLは、classの物理パスではなく登録した対応関係で決まります。たとえばアプリのURLの先頭が /MyWebApp、Servletの登録が /hello なら、アクセス先は /MyWebApp/hello です。

確認資料：Jakarta Servlet 6.1 §10.5・§10.13 / Tomcatの配置構造

srcには.javaがある。でもTomcatが探すのはWEB-INF/classes。どうつながる？

ここで、一つのWebアプリの材料がある側と完成形の側を並べます。WebContent は、この例でWeb用資材を集める開発用フォルダーの名前です。その中身が、完成形のルートへ入ります。

MyWebProject/
├─ src/
│  └─ com/example/HelloServlet.java
├─ lib/
│  └─ library.jar
└─ WebContent/
   ├─ index.jsp
   └─ WEB-INF/

MyWebApp/
├─ index.jsp
└─ WEB-INF/
   ├─ classes/
   │  └─ com/example/HelloServlet.class
   └─ lib/
      └─ library.jar

左のlibは説明用に選んだ保管場所で、自動的に配置されるという意味ではありません。どの資材をどこへ入れるか、対応付けが必要です。

図に増えたもの：classの変換先 ＋ JARの配置先 ＋ Web資材の配置先。

普通のJava Projectと、フォルダーの見え方が違うのはなぜ？

WebアプリではJavaソースだけでなく、JSPや画像もまとめて扱います。そして、完成形ではそれぞれ行き先が違います。その関係をEclipseで管理するためのプロジェクトがDynamic Web Projectです。

HelloProject/
├─ src/             ← Javaソース
└─ bin/             ← class出力

MyWebProject/
├─ src/             ← Javaソース
├─ build/classes/   ← class出力の例
└─ WebContent/      ← Web資材
   ├─ index.jsp
   └─ WEB-INF/

Dynamic Web Projectは、Javaソース・Web資材・配置先との対応を持つ開発用のまとまりです。フォルダーを分ける理由は、classへ変換する材料と、そのままWeb資材として配置する材料を区別するためです。

たとえばWebContentを別名にしても、対応を正しく設定すれば同じ完成形を作れます。Eclipseで見えるプロジェクト全体を、そのままTomcatへコピーするわけではありません。

確認資料：Eclipse Dynamic Web projects（構造の説明を参照。画面の既定値は版・設定で異なります）

Run on Serverを押すと動く。Eclipseは、どうやってTomcatを操作している？

まず、Eclipseを使わずに動かすなら

Tomcatは独立したWebコンテナです。Javaの実行環境とTomcat本体を用意すれば、Eclipseを起動せずにWebアプリを動かせます。ここでは、準備してから起動する流れを見ます。

MyWebApp/
├─ index.jsp
└─ WEB-INF/
   ├─ classes/
   │  └─ com/example/HelloServlet.class
   └─ lib/library.jar

Run on Serverは、この準備と操作をまとめて支援する

まずEclipseのJava機能がソースをコンパイルします。次に、その出力とWeb資材を、Tomcatが読める構成へ配置します。Eclipseでこの配置やサーバー起動を支援する仕組みの一つが、WTP（Web Tools Platform）です。

Deployment Assemblyは「材料 → 行き先」の対応表

プロジェクトのPropertiesで見かけるDeployment Assemblyは、どのフォルダーやライブラリを、完成形のどこへ配置するかを管理する設定です。

説明用の対応例です。表示されるエントリーや初期設定は構成で異なります。Java Build PathにJARを加えることと、Webアプリへ同梱することは同じではありません。

Tomcatを登録する＝「PC上のどのTomcatを使うか」を教える

Tomcat本体をPCへ用意した後、その場所をEclipseへ登録します。これはTomcatをEclipseの中へインストールする操作ではありません。すでにあるインストール先を参照する設定です。

1. Windows版の英語UIでは、Window → Preferences → Server → Runtime Environmentsを開く。
2. Add → Apacheから、用意したTomcatの版に対応する項目を選び、Nextへ進む。
3. Tomcat installation directoryに、Tomcatを展開したフォルダーを指定する。画面で求められるJava実行環境も確認して、Finishで登録する。

メニューと登録先フィールドは公式ヘルプで確認。選択できるTomcatの版・画面の項目は、導入済みのアダプターやEclipseの版で異なります。公式ヘルプ内の古いTomcat一覧を、現在の対応一覧として使わないでください。

C:\apache-tomcat-xx\
├─ bin/
├─ conf/
├─ lib/
├─ logs/
├─ webapps/
└─ …

確認資料：Adding the Apache Tomcat runtimes / Server runtime environments preferences

画面の名前が、何のためにあるか

Serversビューは、サーバーの操作と状態を見る場所

登録したサーバーと、それに追加したWebプロジェクトを一覧で扱います。対象のサーバーを選び、ツールバーや右クリックメニューから操作します。

Servers
└─ Tomcat v10.x Server at localhost  [Started]
   └─ MyWebProject

Startedは「サーバーが起動している」という状態です。編集したすべての変更が反映されたという意味ではありません。サーバーの起動状態と、アプリの同期・Publishの状態を分けて見ます。

確認資料：Servers view

保存 → コンパイル → Publish → Tomcatで実行

ファイルを直してから画面に結果が出るまでを、4段階に分けます。自動処理で続けて起きる場合でも、それぞれ更新する対象が違います。

確認資料：Publishing your application

Tomcat本体のwebappsに、アプリが見当たらない？

Eclipse / WTPでは、本体とは別に管理するTomcat用の作業ディレクトリへ配置することがあります。本体のwebappsにないことだけで、Publishされていないとは判断できません。

配置先を確かめるときは、Serversビューの対象サーバーを開き、Server Locationsなどの設定を確認します。項目名・利用できる設定は版や構成で異なります。大切なのは、実際に起動したTomcatが参照する配置先を見ることです。

確認資料：WTP Tomcat FAQ（旧版を対象とする資料。インストール先と作業場所を分ける仕組みを参照）

変更が見えないときは、ファイルの旅を順にたどる

覚えた仕組みを使うと、確認する場所も分かります。これは原因をすべて網羅する診断表ではなく、「どの段階まで進んだか」を考えるための順番です。

1. HelloServlet.javaは保存した？変更がエディターの中だけに残っていないか。
2. .classは更新された？コンパイルエラーがなく、出力先に新しいclassができたか。
3. Publishされた？対象サーバーの配置へ反映されたか。必要な再読み込みも確認する。
4. Tomcatは起動している？Serversビューで、目的のサーバーの状態を見る。
5. 正しいWebアプリを追加している？Add and Removeで対応付けたプロジェクトを確かめる。
6. 正しいURLへアクセスしている？接続先・ポート・アプリのパス・ServletのURL対応を確かめる。

Run on Serverの内側を、一枚につなぐ

index.jsp
WEB-INF/
├─ classes/com/example/HelloServlet.class
└─ lib/library.jar

4段階で説明しよう：保存 → EclipseのJava機能でコンパイル → WTPでPublish → Tomcatで実行。

覚えること：Java Build Pathは「探す場所」、Deployment Assemblyは「配置する先」。

確認資料：WTP Deployment Assemblyの概要 / Testing and publishing

完成したフォルダー一式を、配りやすくするには？

Tomcatには、展開されたWebアプリのフォルダーを配置する方法もあります。しかし配布時にファイルを一つずつ渡すと、抜けや置き間違いが起きます。そこで、Webアプリの配置構造を保ったまま、一つにまとめたファイルを使います。これがWAR（Web Application Archive）です。

MyWebApp/
├─ index.jsp
└─ WEB-INF/
   ├─ classes/
   │  └─ com/example/HelloServlet.class
   └─ lib/
      └─ library.jar

MyWebApp.war
├─ index.jsp
└─ WEB-INF/
   ├─ classes/
   │  └─ com/example/HelloServlet.class
   └─ lib/
      └─ library.jar

WARの内部のルートはindex.jspやWEB-INFです。通常、外側のMyWebAppフォルダーまで一段余計に包む構成にはしません。また、JARのファイル名を.warへ変えればよいわけではありません。中身がWebアプリのルールに合っている必要があります。

図に増えたもの：そろえたWebアプリの構造 → WAR → Tomcat。

確認資料：Servlet 6.1 §10.6 / Jakarta EE Tutorial / Packaging

ここまでに必要だった作業を振り返ります。Javaソースを書いた後にも、完成したWebアプリへたどり着くまでには、多くの準備があります。

変更するたびに、コピーと変換を全部やり直す？

このように、材料から利用・配布できる成果物を作る一連の作業をビルドと呼びます。コンパイルはその一部です。テストで動きを確かめる作業なども組み合わせられます。

そして、この手順を定義して自動で実行する道具が、MavenやGradleなどのビルドツールです。「classにする・必要なJARを用意する・配置構造を組み立てる・テストする・JARやWARを作る」を、人間の繰り返し作業から引き受けます。

覚えること：ビルドは完成形を作る工程。Maven／Gradleは、その工程を自動化する道具。

今度はsrc/main/java？ WebContentはどこへ行った？

作業を自動化しやすくするために、ビルドツールには「材料をここへ置こう」という標準的な約束があります。MavenやGradleのJava／Web向け機能では、次のような構成がよく使われます。

MyWebProject/
└─ src/
   └─ main/
      ├─ java/
      │  └─ com/example/HelloServlet.java
      ├─ resources/
      │  └─ app.properties
      └─ webapp/
         ├─ index.jsp
         ├─ css/style.css
         └─ WEB-INF/

target/
├─ classes/
│  └─ com/example/HelloServlet.class
└─ MyWebApp.war

build/
├─ classes/java/main/
│  └─ com/example/HelloServlet.class
└─ libs/
   └─ MyWebApp.war

確認資料：Maven Standard Directory Layout / Maven WAR Plugin / Gradle Java Plugin / Gradle War Plugin

これで、プロジェクトによってフォルダーが違って見える理由を説明できます。開発中の材料の置き方と、完成形の配置ルールは、別の約束だからです。

src/
└─ com/example/HelloServlet.java
WebContent/
├─ index.jsp
└─ WEB-INF/

src/main/
├─ java/com/example/HelloServlet.java
├─ resources/
└─ webapp/
   ├─ index.jsp
   └─ WEB-INF/

Webアプリのルート/
├─ index.jsp  （ほかにHTML / CSS / 画像など）
└─ WEB-INF/
   ├─ classes/com/example/HelloServlet.class
   └─ lib/library.jar

「Eclipseかビルドツールか」の二者択一ではありません。Maven／GradleのプロジェクトをEclipseで編集し、Web開発の支援機能を使うこともできます。ここでは分かりやすく、代表的な開発フォルダーの例を比べています。

覚えること：WebContentやsrc/main/webappは材料の場所。完成形では、その中身がアプリのルートへ入る。

どちらも、ここまで見てきた作業を自動化する道具です。最初は、手順と依存関係を書くファイルが違うと捉えれば十分です。

<packaging>war</packaging>

plugins {
    id 'war'
}

依存関係とは「このアプリが使うライブラリなど」のことです。ファイルに名前や版を書いておくと、ツールが指定先から用意してくれます。そのうちコンパイルだけに使うもの、実行時に同梱するものは設定で区別します。

まず、自分はいまどのケース？

Eclipseは作業するIDE、Maven / Gradleはビルドや依存関係を管理する道具です。EclipseとMavenをつなぐ機能がm2e、Gradleをつなぐ機能がBuildshipです。

① まだProjectがない：新しく作る

EclipseからMaven ProjectまたはGradle Projectを新規作成すると、ビルド定義が用意され、そのまま編集できます。

Maven / Gradleで管理するProjectを、Eclipseで編集しているという関係です。現在でもコマンドラインなどでProjectを作れます。その場合は、次の②でEclipseへ取り込みます。

② Projectはもうある：Eclipseで開く

GitやZIPで、次のようなProjectを受け取ったとします。作り直さず、既存のビルド定義を取り込みます。

SampleApp/
├─ pom.xml
└─ src/

SampleApp/
├─ build.gradle
├─ settings.gradle
└─ src/

m2e / Buildshipがソースの場所や依存関係を読み取り、Eclipseで扱えるように構成します。Newは「まだないProjectを作る」、Importは「すでにあるProjectをEclipseで開く」操作です。Importは単なるファイルのコピーではありません。

③ 普通のEclipse Projectへ、後から導入する

HelloProject/
├─ .project
├─ .classpath
├─ src/
└─ lib/
   └─ calculator.jar

1. ビルド定義を用意する。Mavenならpom.xml、Gradleならbuild.gradleなどに、ソースの場所・Java設定・必要なライブラリを定義します。
2. 今ある構成と合わせる。src/を標準のsrc/main/javaへ移すか、現在の場所をビルド定義に指定します。ライブラリもビルドツール側から利用できるようにし、ビルドできることを確かめます。
3. Eclipseへ連携する。Maven用設定をm2eで取り込み、Gradle用設定をBuildshipで取り込んで、Maven / Gradle Projectとして扱います。

m2eには通常のJava ProjectへMavenサポートを加える機能があります。Buildshipには既存ProjectをGradleと連携させるAdd Gradle Natureがあります。連携を有効にするだけで、手動登録した全JARやソース構成が完全なビルド定義へ自動変換されるわけではありません。

具体例：Gradle導入後も、foo.jarをEclipseにだけ追加すると？

導入前は、Java Build Pathでlib/foo.jarを登録していました。Gradle管理へ移した後は、build.gradle側へfoo.jarの依存関係を書くのが基本です。

dependencies {
    implementation files('lib/foo.jar')
}

foo.jarはプロジェクト内のlib/に用意した例です。Java Build Pathへだけ追加すると、Eclipseではエラーが消えても、Gradle側に指定がなければGradleのコンパイルで見つかりません。Maven管理ならpom.xmlへ依存関係を定義します。変更後にEclipseへ反映する操作は、後の「同期」で確認します。

3ケースと、選ぶ操作をまとめる

何が変わった？ Eclipseとのつなぎ方

新しく用意したProjectも、受け取った既存Projectも、Eclipseとのつなぎ方を比べてみましょう。

だから、設定ファイルが複数見える

Eclipse用の設定と、Maven / Gradle用の定義が同じProject内に共存しています。

Gradleにはbuild.gradle.kts / settings.gradle.ktsもあります。ファイルの有無だけで決めず、そのProjectの手順と管理方法を確認します。

変更したら、Eclipseへ同期する

MavenならMaven → Update Project…、GradleならGradle → Refresh Gradle Projectが代表例です。Java Build Pathなどへ変更が反映されます。IDE側だけの手動追加を、逆向きにビルド定義へ書き戻す操作ではありません。

SyncはIDE側の構成を合わせる。PublishはTomcatが使う配置へ反映する。

結局、ライブラリを追加するときはどこを直す？

ビルド設定も、管理するツール側で変更します。文字色などIDE固有の設定はEclipse側です。「誰が読む設定？」「ビルドを管理しているのは誰？」で、変更の基準を判断できます。

確認：2026年10月1日 / m2e / 新規作成・Mavenサポート / Buildship / 作成・Import / Buildship / 操作名・既存Projectとの連携

まず考えるのは、「自分はいま、新しく作るのか、既存Projectを開くのか、後からMaven / Gradleを導入するのか？」

IDEをEclipse以外へ変えたら、Maven / Gradleも変える必要がある？

第14章ではMaven / Gradleという道具を、第15章ではEclipseで使う場面を見ました。最後に、「どのIDEを使うか」と「何でビルドを管理するか」は別々に選べると整理しましょう。

同じpom.xmlを持つProjectも、同じGradle Projectも、EclipseやIntelliJ IDEAで開けます。IDEを変えても、Maven / Gradleによるビルド管理を続けられます。

Eclipseのパッケージを選ぶ場面でも、役割で考える

どちらもJavaを書けます。違いは主に、最初から用意されている開発支援機能です。2026-09の公式パッケージ情報では、次のように説明されています。

Java SE・Java EE・Jakarta EEは、短く整理する

Java SEは、普通のJavaプログラムを作り動かす基盤です。ServletなどのWeb／Enterprise向け仕様は、歴史的にはJava EE、現在はJakarta EEという体系に含まれます。Java SEを土台に利用するもので、別のJava言語ではありません。TomcatはそのうちServletなどを扱う実装で、Jakarta EEの全機能を備えた製品という意味ではありません。

確認資料：m2e / Buildship / Java Developers 2026-09 / Enterprise Java and Web Developers 2026-09

最初はHello.javaが一つあるだけでした。最後に、普通のJavaとWebアプリのファイルの旅を並べます。矢印が「変換」なのか「配置」なのか「実行」なのかに注目してください。

自分の言葉で、説明してみよう

「ボタンを押したら動いた」から、
「自分のファイルの行き先が分かる」へ。

確認日：2026年9月30日。配置のルールはServlet仕様で確認し、開発フォルダーの例は各ツールの文書を参照しました。latest／currentのページは更新されます。Eclipseのヘルプには旧版の画面例が残るため、構造と役割の根拠として利用し、現在の既定フォルダー名とは断定していません。

• Eclipse / Project description file・Java build path persistence・Project-scoped preferences.project・.classpath・プロジェクト固有設定。第15章。
• Maven / Introduction to the POM・Build Lifecycle・Maven Eclipse Plugin / RETIREDPOMの役割、ビルド工程、旧Eclipse設定生成プラグインの保守終了。第15章。
• m2e FAQ・Buildship User Overview・Buildship FAQEclipseへの取込・同期、ビルド定義の依存関係とIDE情報。第15章。
• Gradle / Eclipse Plugins・Gradle 1.0 Release Notes設定生成方式と現在の非推奨範囲、以前からのビルドツールとしての役割。第15章。現在版の参照時9.8.0。
• Gradle / Settings File Basics・Declaring Dependencies・Troubleshooting / IDE synchronization設定の役割、ファイル依存関係、Refresh Gradle Project。第15章。
• IntelliJ IDEA / Build tools importing processMaven／Gradleのビルド情報からIDEの構成を取り込む仕組み。第15章。
• Eclipse / Java Builderソースのコンパイルとclass出力。第1〜2章。
• Eclipse / Java Build Pathソース・出力先・Libraries、Add JARs。第1・4章。
• Oracle / javac commandコンパイルと出力先の指定。第2章。
• Oracle / java commandJVM起動、main、classpath。第2〜3章。
• Oracle / JAR File SpecificationJARの形式とclass・リソースの収録。第3章。
• Jakarta Servlet 6.1 SpecificationServletの実行、§10.5 配置、§10.6 WAR、§10.13 web.xml省略条件。第5〜10章。
• Apache Tomcat / Deploymentclasses・libとパッケージの対応。第6〜7章。
• Jakarta EE Tutorial / PackagingWebアプリの構成とWAR。第10章。
• Eclipse WTP / Dynamic Web projects開発資材とWeb資材の区別。第8章。旧来の構成例を含む資料。
• Eclipse WTP / Deployment Assembly overviewフォルダー・ライブラリと配置先の対応付け。第9章。
• Eclipse WTP / Testing and publishing開発中のサーバー実行と公開。第9章。
• Eclipse / Adding the Apache Tomcat runtimes・Runtime Environments登録メニュー、インストール先の指定、Runtimeの役割。第9章。ヘルプに残る古い対応版一覧は採用していません。
• Eclipse / Servers view・Publishing your applicationStart・Stop・Restart、プロジェクトの追加、Publishと状態の見方。第9章。
• Eclipse / WTP Tomcat FAQTomcat本体と別の作業ディレクトリ、Server Locations。第9章。旧版向け資料を仕組みの根拠として参照。
• Apache Maven / Standard Directory Layoutsrc/main/java・resources・webappとtarget。第12〜13章。
• Apache Maven / WAR PluginWebアプリの組み立てとWAR作成。第11〜14章。
• Gradle / Java PluginJavaソース・リソースとコンパイル出力。第11〜14章。
• Gradle / War Pluginwebappからルート、classからclasses、同梱JARからlibへの対応。第12〜14章。参照時9.8.0。
• Eclipse / m2e・BuildshipEclipseとビルドツールの連携。第16章。
• JetBrains / Gradle projects・Maven projectsIDEでの構成読込とビルド実行。第16章。2026.2 Help。
• Eclipse / Java Developers 2026-09Java開発用パッケージの同梱機能。第16章。
• Eclipse / Enterprise Java and Web Developers 2026-09Web開発用パッケージの同梱機能。第16章。
• Jakarta EE / Platform Specification 9Java SEとの関係と名前空間の移行。第16章の補足。

フォルダー図は責務と対応を学ぶための例です。内側のパッケージ階層は一部、com/exampleのように短く表記しています。ファイルを選ぶ操作は概念の表示であり、実際のコンパイル・配置は実行しません。