Spring Boot 2.6.3 での開発 - リファレンスドキュメント

このセクションでは、Spring Boot の使用方法について詳しく説明します。ビルドシステム、自動構成、アプリケーションの実行方法などのトピックを扱います。また、Spring Boot のベストプラクティスもいくつか取り上げています。Spring Boot に関して特別なことは何もありませんが（それは使用する単なるライブラリにすぎません）、従えば、開発プロセスを少し簡単にするいくつかの推奨事項があります。

Spring Boot を使用する場合は、このセクションに進む前に入門ガイドを参照してください。

1. ビルドシステム

依存関係管理をサポートし、"Maven Central" リポジトリに公開されたアーティファクトを利用できる Gradle または Maven を選択することをお勧めします。Spring Boot 2.3 以降、Spring Framework や Spring Boot などのビルドには Maven ではなく Gradle が使用 (英語) されています。Spring Boot を他のビルドシステム（Ant など）で動作させることは可能ですが、特に十分にサポートされていません。

1.1. 依存関係管理

Spring Boot の各リリースは、サポートしている依存関係のリストを提供しています。Spring Boot が管理しているため、実際には、ビルド設定でこれらの依存関係のバージョンを指定する必要はありません。Spring Boot 自体をアップグレードすると、これらの依存関係も一貫した方法でアップグレードされます。

バージョンを指定して、必要に応じて Spring Boot の推奨を上書きすることもできます。

厳選されたリストには、Spring Boot で使用できるすべての Spring モジュールと、サードパーティライブラリの洗練されたリストが含まれています。このリストは、Gradle と Maven の両方で使用できる標準の部品表（spring-boot-dependencies）として入手できます。

Spring Boot の各リリースは、Spring Framework の基本バージョンに関連付けられています。バージョンを指定しないことを強くお勧めします。

1.2. Maven

Maven で Spring Boot を使用する方法については、Spring Boot の Maven プラグインのドキュメントを参照してください。

リファレンス ( HTML および PDF (英語) )
API

1.3. Gradle

Gradle で Spring Boot を使用する方法については、Spring Boot の Gradle プラグインのドキュメントを参照してください。

リファレンス ( HTML および PDF (英語) )
API

1.4. Ant

Apache Ant+Ivy を使用して Spring Boot プロジェクトをビルドすることができます。spring-boot-antlib "AntLib" モジュールも利用可能で、Ant が実行可能な jar を作成できます。

依存関係を宣言するための一般的な ivy.xml ファイルは、次の例のようになります。

<ivy-module version="2.0">
    <info organisation="org.springframework.boot" module="spring-boot-sample-ant" />
    <configurations>
        <conf name="compile" description="everything needed to compile this module" />
        <conf name="runtime" extends="compile" description="everything needed to run this module" />
    </configurations>
    <dependencies>
        <dependency org="org.springframework.boot" name="spring-boot-starter"
            rev="${spring-boot.version}" conf="compile" />
    </dependencies>
</ivy-module>

典型的な build.xml は、次の例のようになります。

<project
    xmlns:ivy="antlib:org.apache.ivy.ant"
    xmlns:spring-boot="antlib:org.springframework.boot.ant"
    name="myapp" default="build">

    <property name="spring-boot.version" value="2.6.3" />

    <target name="resolve" description="--> retrieve dependencies with ivy">
        <ivy:retrieve pattern="lib/[conf]/[artifact]-[type]-[revision].[ext]" />
    </target>

    <target name="classpaths" depends="resolve">
        <path id="compile.classpath">
            <fileset dir="lib/compile" includes="*.jar" />
        </path>
    </target>

    <target name="init" depends="classpaths">
        <mkdir dir="build/classes" />
    </target>

    <target name="compile" depends="init" description="compile">
        <javac srcdir="src/main/java" destdir="build/classes" classpathref="compile.classpath" />
    </target>

    <target name="build" depends="compile">
        <spring-boot:exejar destfile="build/myapp.jar" classes="build/classes">
            <spring-boot:lib>
                <fileset dir="lib/runtime" />
            </spring-boot:lib>
        </spring-boot:exejar>
    </target>
</project>

spring-boot-antlib モジュールを使用したくない場合は、howto.html 「使い方」を参照してください。

1.5. スターター

スターターは、アプリケーションに含めることができる便利な依存関係記述子のセットです。必要なすべての Spring および関連テクノロジーのワンストップショップを利用して、サンプルコードを探したり、依存関係記述子のコピーアンドペーストを行う必要はありません。例: データベースアクセスに Spring と JPA の使用を開始する場合は、プロジェクトに spring-boot-starter-data-jpa 依存関係を含めます。

スターターには、プロジェクトを迅速に立ち上げて実行するために必要な多くの依存関係と、管理された推移的な依存関係のサポートされたセットが含まれています。

名前に含まれる意味

すべての公式スターターは、spring-boot-starter-* のような命名パターンに従います。* は特定のタイプのアプリケーションです。この命名構造は、スターターを見つける必要がある場合に役立つことを目的としています。多くの IDE に Maven が統合されているため、依存関係を名前で検索できます。例: 適切な Eclipse または Spring Tools プラグインがインストールされている場合、POM エディターで ctrl-space を押し、"spring-boot-starter" と入力して完全なリストを表示できます。

"独自のスターターを作成する" セクションで説明したように、サードパーティのスターターは公式の Spring Boot アーティファクト用に予約されているため、spring-boot で開始しないでください。むしろ、サードパーティのスターターは通常、プロジェクトの名前で始まります。例: thirdpartyproject というサードパーティのスタータープロジェクトは、通常 thirdpartyproject-spring-boot-starter という名前になります。

次のアプリケーションスターターは、org.springframework.boot グループで Spring Boot によって提供されます。

表 1: Spring Boot アプリケーションスターター
名前	説明
`spring-boot-starter`	自動構成サポート、ロギング、YAML を含むコアスターター
`spring-boot-starter-activemq`	Apache ActiveMQ を使用した JMS メッセージングのスターター
`spring-boot-starter-amqp`	Spring AMQP および Rabbit MQ を使用するためのスターター
`spring-boot-starter-aop`	Spring AOP および AspectJ を使用したアスペクト指向プログラミングのスターター
`spring-boot-starter-artemis`	Apache Artemis を使用した JMS メッセージングのスターター
`spring-boot-starter-batch`	Spring Batch を使用するためのスターター
`spring-boot-starter-cache`	Spring Framework のキャッシュサポートを使用するためのスターター
`spring-boot-starter-data-cassandra`	Cassandra 分散データベースおよび Spring Data Cassandra を使用するためのスターター
`spring-boot-starter-data-cassandra-reactive`	Cassandra 分散データベースおよび Spring Data Cassandra Reactive を使用するためのスターター
`spring-boot-starter-data-couchbase`	Couchbase ドキュメント指向データベースおよび Spring Data Couchbase を使用するためのスターター
`spring-boot-starter-data-couchbase-reactive`	Couchbase ドキュメント指向データベースおよび Spring Data Couchbase Reactive を使用するためのスターター
`spring-boot-starter-data-elasticsearch`	Elasticsearch 検索および分析エンジンと Spring Data Elasticsearch を使用するためのスターター
`spring-boot-starter-data-jdbc`	Spring Data JDBC を使用するためのスターター
`spring-boot-starter-data-jpa`	Hibernate で Spring Data JPA を使用するためのスターター
`spring-boot-starter-data-ldap`	Spring Data LDAP を使用するためのスターター
`spring-boot-starter-data-mongodb`	MongoDB ドキュメント指向データベースと Spring Data MongoDB を使用するためのスターター
`spring-boot-starter-data-mongodb-reactive`	MongoDB ドキュメント指向データベースと Spring Data MongoDB リアクティブを使用するためのスターター
`spring-boot-starter-data-neo4j`	Neo4j グラフデータベースと Spring Data Neo4j を使用するためのスターター
`spring-boot-starter-data-r2dbc`	Spring Data R2DBC を使用するためのスターター
`spring-boot-starter-data-redis`	Spring Data Redis および Lettuce クライアントで Redis Key-Value データストアを使用するためのスターター
`spring-boot-starter-data-redis-reactive`	Spring Data Redis リアクティブおよび Lettuce クライアントで Redis キー値データストアを使用するためのスターター
`spring-boot-starter-data-rest`	Spring Data REST を使用して REST 経由で Spring Data リポジトリを公開するためのスターター
`spring-boot-starter-freemarker`	FreeMarker ビューを使用して MVC Web アプリケーションを構築するためのスターター
`spring-boot-starter-groovy-templates`	Groovy テンプレートビューを使用して MVC Web アプリケーションを構築するためのスターター
`spring-boot-starter-hateoas`	Spring MVC および Spring HATEOAS を使用してハイパーメディアベースの RESTful Web アプリケーションを構築するためのスターター
`spring-boot-starter-integration`	Spring Integration を使用するためのスターター
`spring-boot-starter-jdbc`	HikariCP 接続プールで JDBC を使用するためのスターター
`spring-boot-starter-jersey`	JAX-RS および Jersey を使用して RESTful Web アプリケーションを構築するためのスターター。`spring-boot-starter-web` の代替
`spring-boot-starter-jooq`	jOOQ を使用して JDBC で SQL データベースにアクセスするためのスターター。`spring-boot-starter-data-jpa` または `spring-boot-starter-jdbc` の代替
`spring-boot-starter-json`	JSON を読み書きするためのスターター
`spring-boot-starter-jta-atomikos`	Atomikos を使用した JTA トランザクションのスターター
`spring-boot-starter-mail`	Java Mail および Spring Framework のメール送信サポートを使用するためのスターター
`spring-boot-starter-mustache`	Mustache ビューを使用して Web アプリケーションを構築するためのスターター
`spring-boot-starter-oauth2-client`	Spring Security の OAuth2/OpenID Connect クライアント機能を使用するためのスターター
`spring-boot-starter-oauth2-resource-server`	Spring Security の OAuth2 リソースサーバー機能を使用するためのスターター
`spring-boot-starter-quartz`	Quartz スケジューラーを使用するためのスターター
`spring-boot-starter-rsocket`	RSocket クライアントおよびサーバーを構築するためのスターター
`spring-boot-starter-security`	Spring Security を使用するためのスターター
`spring-boot-starter-test`	JUnit Jupiter、Hamcrest、Mockito などのライブラリを使用して Spring Boot アプリケーションをテストするためのスターター
`spring-boot-starter-thymeleaf`	Thymeleaf ビューを使用して MVC Web アプリケーションを構築するためのスターター
`spring-boot-starter-validation`	Hibernate Validator で Java Bean Validation を使用するためのスターター
`spring-boot-starter-web`	Spring MVC を使用して、RESTful を含む Web アプリケーションを構築するためのスターター。デフォルトの埋め込みコンテナーとして Tomcat を使用
`spring-boot-starter-web-services`	Spring Web Services を使用するためのスターター
`spring-boot-starter-webflux`	Spring Framework の Reactive Web サポートを使用して WebFlux アプリケーションを構築するためのスターター
`spring-boot-starter-websocket`	Spring Framework の WebSocket サポートを使用して WebSocket アプリケーションを構築するためのスターター

アプリケーションスターターに加えて、次のスターターを使用して、本番対応機能を追加できます。

表 2: Spring Boot 本番スターター
名前	説明
`spring-boot-starter-actuator`	Spring Boot のアクチュエーターを使用するためのスターター。アプリケーションの監視と管理に役立つ本番対応機能を提供します

最後に、Spring Boot には、特定の技術ファセットを除外または交換する場合に使用できる次のスターターも含まれています。

表 3: Spring Boot テクニカルスターター
名前	説明
`spring-boot-starter-jetty`	Jetty を埋め込みサーブレットコンテナーとして使用するためのスターター。`spring-boot-starter-tomcat` の代替
`spring-boot-starter-log4j2`	ロギングに Log4j2 を使用するためのスターター。`spring-boot-starter-logging` の代替
`spring-boot-starter-logging`	Logback を使用したロギングのスターター。デフォルトのロギングスターター
`spring-boot-starter-reactor-netty`	Reactor Netty を組み込みのリアクティブ HTTP サーバーとして使用するためのスターター。
`spring-boot-starter-tomcat`	Tomcat を埋め込みサーブレットコンテナーとして使用するためのスターター。`spring-boot-starter-web` が使用するデフォルトのサーブレットコンテナースターター
`spring-boot-starter-undertow`	Undertow を埋め込みサーブレットコンテナーとして使用するためのスターター。`spring-boot-starter-tomcat` の代替

テクニカルファセットを交換する方法については、Web サーバーとロギングシステムの交換に関する使い方ドキュメントを参照してください。

コミュニティが提供するその他のスターターのリストについては、GitHub の spring-boot-starters モジュールの README ファイル [GitHub] (英語) を参照してください。

2. コードの構造化

Spring Boot は、動作するために特定のコードレイアウトを必要としません。ただし、役立つベストプラクティスがいくつかあります。

2.1. 「デフォルト」パッケージの使用

クラスに package 宣言が含まれていない場合、そのクラスは「デフォルトパッケージ」にあると見なされます。通常、「デフォルトパッケージ」の使用は推奨されておらず、避ける必要があります。すべての jar のすべてのクラスが読み取られるため、@ComponentScan、@ConfigurationPropertiesScan、@EntityScan、@SpringBootApplication アノテーションを使用する Spring Boot アプリケーションで特定の問題を引き起こす可能性があります。

Java の推奨パッケージ命名規則に従い、逆ドメイン名（たとえば、com.example.project）を使用することをお勧めします。

2.2. メインアプリケーションクラスの特定

通常、メインアプリケーションクラスを他のクラスの上にあるルートパッケージに配置することをお勧めします。@SpringBootApplication アノテーションは多くの場合メインクラスに配置され、特定のアイテムのベース「検索パッケージ」を暗黙的に定義します。例: JPA アプリケーションを作成している場合、@SpringBootApplication アノテーション付きクラスのパッケージを使用して @Entity アイテムを検索します。ルートパッケージを使用すると、コンポーネントスキャンをプロジェクトにのみ適用することもできます。

@SpringBootApplication を使用したくない場合は、インポートする @EnableAutoConfiguration および @ComponentScan アノテーションがその動作を定義するため、代わりに使用することもできます。

次のリストは、典型的なレイアウトを示しています。

com
 +- example
     +- myapplication
         +- MyApplication.java
         |
         +- customer
         |   +- Customer.java
         |   +- CustomerController.java
         |   +- CustomerService.java
         |   +- CustomerRepository.java
         |
         +- order
             +- Order.java
             +- OrderController.java
             +- OrderService.java
             +- OrderRepository.java

MyApplication.java ファイルは、次のように、基本的な @SpringBootApplication とともに main メソッドを宣言します。

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class MyApplication {

    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }

}

3. 構成クラス

Spring Boot は Java ベースの構成を優先します。SpringApplication を XML ソースで使用することは可能ですが、通常、プライマリソースは単一の @Configuration クラスにすることをお勧めします。通常、main メソッドを定義するクラスは、プライマリ @Configuration として適切な候補です。

XML 構成を使用する多くの Spring 構成例がインターネットで公開されています。可能であれば、常に同等の Java ベースの構成を使用してください。Enable* アノテーションを検索することは、出発点として適切です。

3.1. 追加の構成クラスのインポート

すべての @Configuration を単一のクラスに入れる必要はありません。@Import アノテーションを使用して、追加の構成クラスをインポートできます。または、@ComponentScan を使用して、@Configuration クラスを含むすべての Spring コンポーネントを自動的に取得できます。

3.2. XML 設定のインポート

絶対に XML ベースの構成を使用する必要がある場合は、@Configuration クラスから開始することをお勧めします。その後、@ImportResource アノテーションを使用して XML 構成ファイルをロードできます。

4. 自動構成

Spring Boot 自動構成は、追加した jar 依存関係に基づいて、Spring アプリケーションを自動的に構成しようとします。例: HSQLDB がクラスパス上にあり、データベース接続 Bean を手動で構成していない場合、Spring Boot はメモリ内データベースを自動構成します。

@EnableAutoConfiguration または @SpringBootApplication アノテーションを @Configuration クラスの 1 つに追加して、自動構成をオプトインする必要があります。

@SpringBootApplication または @EnableAutoConfiguration アノテーションを 1 つだけ追加してください。通常、プライマリ @Configuration クラスのみにいずれかを追加することをお勧めします。

4.1. 自動構成の段階的な置き換え

自動構成は非侵襲的です。いつでも、独自の構成を定義して、自動構成の特定の部分を置き換えることができます。例: 独自の DataSource Bean を追加すると、デフォルトの組み込みデータベースサポートは無効になります。

現在適用されている自動構成とその理由を調べる必要がある場合は、--debug スイッチを使用してアプリケーションを開始してください。これにより、選択したコアロガーのデバッグログが有効になり、コンソールに状態レポートが記録されます。

4.2. 特定の自動構成クラスを無効にする

不要な特定の自動構成クラスが適用されている場合は、次の例に示すように、@SpringBootApplication の exclude 属性を使用して無効にすることができます。

import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration;

@SpringBootApplication(exclude = { DataSourceAutoConfiguration.class })
public class MyApplication {

}

クラスがクラスパス上にない場合は、アノテーションの excludeName 属性を使用して、代わりに完全修飾名を指定できます。@SpringBootApplication、exclude、excludeName ではなく @EnableAutoConfiguration を使用したい場合は、こちらもご利用いただけます。最後に、spring.autoconfigure.exclude プロパティを使用して、除外する自動構成クラスのリストを制御することもできます。

アノテーションレベルとプロパティの使用の両方で除外を定義できます。

自動構成クラスは public ですが、パブリック API と見なされるクラスの唯一の側面は、自動構成を無効にするために使用できるクラスの名前です。ネストされた構成クラスや Bean メソッドなど、これらのクラスの実際の内容は内部使用専用であり、直接使用することはお勧めしません。

5. Spring Bean と依存性注入

標準の Spring Framework 手法を自由に使用して、Bean とその注入された依存関係を定義できます。通常、コンストラクターインジェクションを使用して依存関係を接続し、@ComponentScan を使用して Bean を検索することをお勧めします。

上記のようにコードを構造化する場合（アプリケーションクラスを最上位パッケージに配置する場合）、引数なしで @ComponentScan を追加するか、暗黙的にそれを含む @SpringBootApplication アノテーションを使用できます。すべてのアプリケーションコンポーネント（@Component、@Service、@Repository、@Controller など）は、Spring Bean として自動的に登録されます。

次の例は、コンストラクターインジェクションを使用して必要な RiskAssessor Bean を取得する @Service Bean を示しています。

import org.springframework.stereotype.Service;

@Service
public class MyAccountService implements AccountService {

    private final RiskAssessor riskAssessor;

    public MyAccountService(RiskAssessor riskAssessor) {
        this.riskAssessor = riskAssessor;
    }

    // ...

}

Bean に複数のコンストラクターがある場合は、Spring で @Autowired で使用するコンストラクターをマークする必要があります。

import java.io.PrintStream;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class MyAccountService implements AccountService {

    private final RiskAssessor riskAssessor;

    private final PrintStream out;

    @Autowired
    public MyAccountService(RiskAssessor riskAssessor) {
        this.riskAssessor = riskAssessor;
        this.out = System.out;
    }

    public MyAccountService(RiskAssessor riskAssessor, PrintStream out) {
        this.riskAssessor = riskAssessor;
        this.out = out;
    }

    // ...

}

コンストラクターインジェクションを使用すると、riskAssessor フィールドが final としてマークされ、その後変更できないことを示すことに注意してください。

6. @SpringBootApplication アノテーションの使用

多くの Spring Boot 開発者は、自動構成、コンポーネントスキャンを使用し、「アプリケーションクラス」で追加の構成を定義できるアプリを好みます。単一の @SpringBootApplication アノテーションを使用して、これらの 3 つの機能を有効にできます。

@EnableAutoConfiguration: Spring Boot の自動構成メカニズムを有効にする
@ComponentScan: アプリケーションが配置されているパッケージで @Component スキャンを有効にします ( ベストプラクティスを見る)
@SpringBootConfiguration: コンテキストでの追加の Bean の登録、または追加の構成クラスのインポートを有効にします。統合テストでの構成検出を支援する Spring の標準 @Configuration の代替。

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication // same as @SpringBootConfiguration @EnableAutoConfiguration
                        // @ComponentScan
public class MyApplication {

    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }

}

@SpringBootApplication は、@EnableAutoConfiguration および @ComponentScan の属性をカスタマイズするエイリアスも提供します。

これらの機能はいずれも必須ではなく、この単一のアノテーションを有効にする機能のいずれかに置き換えることもできます。たとえば、アプリケーションでコンポーネントスキャンまたは構成プロパティスキャンを使用したくない場合があります。

import org.springframework.boot.SpringApplication;
import org.springframework.boot.SpringBootConfiguration;
import org.springframework.boot.autoconfigure.EnableAutoConfiguration;
import org.springframework.context.annotation.Import;

@SpringBootConfiguration(proxyBeanMethods = false)
@EnableAutoConfiguration
@Import({ SomeConfiguration.class, AnotherConfiguration.class })
public class MyApplication {

    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }

}

この例では、MyApplication は他の Spring Boot アプリケーションとまったく同じですが、@Component アノテーション付きクラスと @ConfigurationProperties アノテーション付きクラスが自動的に検出されず、ユーザー定義 Bean が明示的にインポートされる点が異なります（@Import を参照）。

7. アプリケーションを実行する

アプリケーションを jar としてパッケージ化し、組み込み HTTP サーバーを使用する最大の利点の 1 つは、他のアプリケーションと同じようにアプリケーションを実行できることです。このサンプルは、Spring Boot アプリケーションのデバッグに適用されます。特別な IDE プラグインや拡張機能は必要ありません。

このセクションでは、jar ベースのパッケージについてのみ説明します。アプリケーションを war ファイルとしてパッケージ化することを選択した場合は、サーバーと IDE のドキュメントを参照してください。

7.1. IDE から実行する

IDE から Spring Boot アプリケーションを Java アプリケーションとして実行できます。ただし、最初にプロジェクトをインポートする必要があります。インポート手順は、IDE とビルドシステムによって異なります。ほとんどの IDE は Maven プロジェクトを直接インポートできます。例: Eclipse STS ユーザーは、File メニューから Import… → Existing Maven Projects を選択できます。

プロジェクトを IDE に直接インポートできない場合は、ビルドプラグインを使用して IDE メタデータを生成できる場合があります。Maven には、Eclipse [Apache] (英語) および IDEA [Apache] (英語) のプラグインが含まれています。Gradle は、さまざまな IDE (英語) のプラグインを提供します。

誤って Web アプリケーションを 2 回実行すると、「ポートはすでに使用されています」というエラーが表示されます。Eclipse Spring Tools ユーザーは、Run ボタンではなく Relaunch ボタンを使用して、既存のインスタンスを確実に閉じることができます。

7.2. パッケージ化されたアプリケーションとして実行する

Spring Boot Maven または Gradle プラグインを使用して実行可能 jar を作成する場合、次の例に示すように、java -jar を使用してアプリケーションを実行できます。

$ java -jar target/myapplication-0.0.1-SNAPSHOT.jar

リモートデバッグサポートを有効にしてパッケージ化されたアプリケーションを実行することもできます。これにより、次の例に示すように、パッケージ化されたアプリケーションにデバッガーを接続できます。

$ java -Xdebug -Xrunjdwp:server=y,transport=dt_socket,address=8000,suspend=n \
       -jar target/myapplication-0.0.1-SNAPSHOT.jar

7.3. Maven プラグインの使用

Spring Boot Maven プラグインには、アプリケーションをすばやくコンパイルして実行するために使用できる run ゴールが含まれています。IDE の場合と同様に、アプリケーションは展開された形式で実行されます。次の例は、Spring Boot アプリケーションを実行する典型的な Maven コマンドを示しています。

$ mvn spring-boot:run

次の例に示すように、MAVEN_OPTS オペレーティングシステム環境変数を使用することもできます。

$ export MAVEN_OPTS=-Xmx1024m

7.4. Gradle プラグインの使用

Spring Boot Gradle プラグインには、アプリケーションを展開形式で実行するために使用できる bootRun タスクも含まれています。bootRun タスクは、org.springframework.boot および java プラグインを適用するたびに追加され、次の例に示されています。

$ gradle bootRun

次の例に示すように、JAVA_OPTS オペレーティングシステム環境変数を使用することもできます。

$ export JAVA_OPTS=-Xmx1024m

7.5. ホットスワップ

Spring Boot アプリケーションはプレーン Java アプリケーションであるため、JVM ホットスワップはそのまま使用できます。JVM のホットスワップは、置き換えることができるバイトコードによって多少制限されます。より完全なソリューションには、JRebel (英語) を使用できます。

spring-boot-devtools モジュールには、アプリケーションの迅速な再起動のサポートも含まれています。詳細については、ホットスワップ「使い方」を参照してください。

8. 開発者ツール

Spring Boot には、アプリケーション開発エクスペリエンスをもう少し快適にすることができる追加のツールセットが含まれています。spring-boot-devtools モジュールを任意のプロジェクトに含めて、追加の開発時機能を提供できます。devtools サポートを含めるには、Maven および Gradle の次のように、ビルドにモジュール依存関係を追加します。

Maven

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-devtools</artifactId>
        <optional>true</optional>
    </dependency>
</dependencies>

Gradle

dependencies {
    developmentOnly("org.springframework.boot:spring-boot-devtools")
}

完全にパッケージ化されたアプリケーションを実行すると、開発者ツールは自動的に無効になります。アプリケーションが java -jar から起動された場合、または特別なクラスローダーから起動された場合、「本番アプリケーション」と見なされます。この動作は、spring.devtools.restart.enabled システムプロパティを使用して制御できます。アプリケーションの起動に使用されるクラスローダーに関係なく、devtools を有効にするには、-Dspring.devtools.restart.enabled=true システムプロパティを設定します。これは、devtools の実行がセキュリティリスクとなる本番環境では実行しないでください。devtools を無効にするには、依存関係を除外するか、-Dspring.devtools.restart.enabled=false システムプロパティを設定します。

Maven で依存関係にオプションのフラグを立てるか、Gradle で developmentOnly 構成を使用すると（上記のように）、プロジェクトを使用する他のモジュールに devtools が一時的に適用されなくなります。

再パッケージ化されたアーカイブには、デフォルトでは devtools が含まれません。特定のリモート devtools 機能を使用したい場合は、それを含める必要があります。Maven プラグインを使用する場合は、excludeDevtools プロパティを false に設定します。Gradle プラグインを使用する場合は、developmentOnly 構成を含むようにタスクのクラスパスを構成します。

8.1. プロパティのデフォルト

Spring Boot がサポートするライブラリのいくつかは、キャッシュを使用してパフォーマンスを向上させます。例: テンプレートエンジンは、コンパイルされたテンプレートをキャッシュして、テンプレートファイルを繰り返し解析しないようにします。また、Spring MVC は、静的リソースを提供するときに、レスポンスに HTTP キャッシングヘッダーを追加できます。

キャッシュは本番環境では非常に有益ですが、開発中は逆効果になる可能性があり、アプリケーションで行った変更を確認できなくなります。このため、spring-boot-devtools はデフォルトでキャッシュオプションを無効にします。

キャッシュオプションは通常、application.properties ファイルの設定によって構成されます。例: Thymeleaf は spring.thymeleaf.cache プロパティを提供します。spring-boot-devtools モジュールは、これらのプロパティを手動で設定する必要があるのではなく、適切な開発時構成を自動的に適用します。

Spring MVC および Spring WebFlux アプリケーションの開発中に Web リクエストに関する詳細情報が必要になるため、開発者ツールでは、web ロギンググループに対して DEBUG ロギングを有効にすることをお勧めします。これにより、受信リクエスト、それを処理しているハンドラー、レスポンス結果、その他の詳細に関する情報が得られます。すべてのリクエストの詳細（機密情報を含む）をログに記録する場合は、spring.mvc.log-request-details または spring.codec.log-request-details 構成プロパティをオンにすることができます。

プロパティのデフォルトを適用したくない場合は、application.properties で spring.devtools.add-properties を false に設定できます。

devtools によって適用されるプロパティの完全なリストについては、DevToolsPropertyDefaultsPostProcessor [GitHub] (英語) を参照してください。

8.2. 自動再起動

spring-boot-devtools を使用するアプリケーションは、クラスパス上のファイルが変更されるたびに自動的に再起動します。これは IDE で作業するときに便利な機能です。コードの変更に対して非常に高速なフィードバックループを提供するためです。デフォルトでは、ディレクトリを指すクラスパスのエントリはすべて変更が監視されます。静的アセットやビューテンプレートなどの特定のリソースは、アプリケーションを再起動する必要がないことに注意してください。

再起動のトリガー

DevTools はクラスパスリソースを監視するため、再起動をトリガーする唯一の方法は、クラスパスを更新することです。クラスパスを更新する方法は、使用している IDE によって異なります。

Eclipse では、変更されたファイルを保存すると、クラスパスが更新され、再起動がトリガーされます。
IntelliJ IDEA では、プロジェクト（Build +→+ Build Project）をビルドしても同じ効果があります。
ビルドプラグインを使用している場合、Maven の場合は mvn compile を実行するか、Gradle の場合は gradle build を実行すると再起動がトリガーされます。

ビルドプラグインを使用して Maven または Gradle で再起動する場合は、forking を enabled に設定したままにする必要があります。フォークを無効にすると、devtools によって使用される分離されたアプリケーションクラスローダーが作成されず、再起動が正しく動作しません。

自動再起動は、LiveReload と併用すると非常にうまく機能します。詳細については、LiveReload セクションを参照してください。JRebel を使用する場合、動的なクラスの再読み込みを優先して自動再起動が無効になります。その他の devtools 機能（LiveReload やプロパティのオーバーライドなど）は引き続き使用できます。

DevTools は、アプリケーションコンテキストのシャットダウンフックに依存して、再起動中に閉じます。シャットダウンフック（SpringApplication.setRegisterShutdownHook(false)）を無効にした場合、正しく機能しません。

DevTools は、ApplicationContext が使用する ResourceLoader をカスタマイズする必要があります。アプリケーションがすでに提供している場合、ラップされます。ApplicationContext での getResource メソッドの直接オーバーライドはサポートされていません。

AspectJ ウィービングを使用している場合、自動再起動はサポートされていません。

再起動とリロード

Spring Boot が提供する再起動テクノロジは、2 つのクラスローダーを使用して機能します。変更されないクラス（たとえば、サードパーティの jar からのクラス）は、基本クラスローダーにロードされます。積極的に開発しているクラスは、再起動クラスローダーにロードされます。アプリケーションを再起動すると、再起動クラスローダーが破棄され、新しいクラスローダーが作成されます。このアプローチは、基本クラスローダーがすでに利用可能であり、データが設定されているため、通常、アプリケーションの再起動は「コールドスタート」よりもはるかに高速であることを意味します。

アプリケーションの再起動が十分に速くない場合、またはクラスローディングの問題が発生した場合は、ZeroTurnaround の JRebel (英語) などのテクノロジを再ロードすることを検討できます。これらは、ロードされたときにクラスを書き換えて、再ロードしやすくすることで機能します。

8.2.1. 状態評価の変更の記録

デフォルトでは、アプリケーションを再起動するたびに、状態評価デルタを示すレポートが記録されます。このレポートには、Bean の追加や削除、構成プロパティの設定などの変更を行うと、アプリケーションの自動構成に対する変更が表示されます。

レポートのログを無効にするには、次のプロパティを設定します。

Properties

spring.devtools.restart.log-condition-evaluation-delta=false

Yaml

spring:
  devtools:
    restart:
      log-condition-evaluation-delta: false

8.2.2. リソースを除外する

特定のリソースは、変更されたときに必ずしも再起動をトリガーする必要はありません。例: Thymeleaf テンプレートはその場で編集できます。デフォルトでは、/META-INF/maven、/META-INF/resources、/resources、/static、/public または /templates のリソースを変更しても再起動はトリガーされませんが、ライブリロードはトリガーされます。これらの除外をカスタマイズする場合は、spring.devtools.restart.exclude プロパティを使用できます。例: /static と /public のみを除外するには、次のプロパティを設定します。

Properties

spring.devtools.restart.exclude=static/**,public/**

Yaml

spring:
  devtools:
    restart:
      exclude: "static/**,public/**"

これらのデフォルトを維持して除外を追加する場合は、代わりに spring.devtools.restart.additional-exclude プロパティを使用します。

8.2.3. 追加パスの監視

クラスパスにないファイルに変更を加えた場合、アプリケーションを再起動または再ロードすることができます。これを行うには、spring.devtools.restart.additional-paths プロパティを使用して、変更を監視する追加のパスを構成します。前述の spring.devtools.restart.exclude プロパティを使用して、追加のパスにある変更が完全な再起動またはライブリロードをトリガーするかどうかを制御できます。

8.2.4. 再起動を無効にする

再起動機能を使用しない場合は、spring.devtools.restart.enabled プロパティを使用して無効にすることができます。ほとんどの場合、application.properties でこのプロパティを設定できます（そうすると、再起動クラスローダーが初期化されますが、ファイルの変更は監視されません）。

再起動サポートを完全に無効にする必要がある場合（たとえば、特定のライブラリでは機能しないため）、次の例に示すように、SpringApplication.run(…) を呼び出す前に spring.devtools.restart.enabledSystem プロパティを false に設定する必要があります。

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class MyApplication {

    public static void main(String[] args) {
        System.setProperty("spring.devtools.restart.enabled", "false");
        SpringApplication.run(MyApplication.class, args);
    }

}

8.2.5. トリガーファイルの使用

変更されたファイルを継続的にコンパイルする IDE を使用している場合、特定の時間にのみ再起動をトリガーすることをお勧めします。そのためには、「トリガーファイル」を使用できます。これは、実際に再起動チェックをトリガーするときに変更する必要がある特別なファイルです。

ファイルを更新すると、チェックがトリガーされますが、再起動は、Devtools が何らかの処理を行うことを検出した場合にのみ実際に発生します。

トリガーファイルを使用するには、spring.devtools.restart.trigger-file プロパティをトリガーファイルの名前（パスを除く）に設定します。トリガーファイルは、クラスパスのどこかに表示する必要があります。

例: 次の構造のプロジェクトがある場合:

src
+- main
   +- resources
      +- .reloadtrigger

trigger-file プロパティは次のようになります。

Properties

spring.devtools.restart.trigger-file=.reloadtrigger

Yaml

spring:
  devtools:
    restart:
      trigger-file: ".reloadtrigger"

再起動は、src/main/resources/.reloadtrigger が更新されたときにのみ発生します。

すべてのプロジェクトが同じように動作するように、spring.devtools.restart.trigger-file をグローバル設定として設定できます。

一部の IDE には、トリガーファイルの手動更新を不要にする機能があります。Pleiades All in One (JDK, STS, Lombok 付属) または Eclipse 用 Spring Tools (英語) と IntelliJ IDEA (Ultimate エディション) (英語) は両方ともそのようなサポートを持っています。Spring Tools では、コンソールビューから「リロード」ボタンを使用できます（trigger-file の名前が .reloadtrigger である限り）。IntelliJ IDEA については、このドキュメントの指示 (英語) に従ってください。

8.2.6. 再起動クラスローダーのカスタマイズ

再起動とリロードセクションで前述したように、再起動機能は 2 つのクラスローダーを使用して実装されます。ほとんどのアプリケーションでは、このアプローチはうまく機能します。ただし、クラスロードの問題が発生する場合があります。

デフォルトでは、IDE で開いているプロジェクトはすべて「再起動」クラスローダーでロードされ、通常の .jar ファイルは「ベース」クラスローダーでロードされます。すべてのモジュールが IDE にインポートされるわけではなく、マルチモジュールプロジェクトで作業している場合は、カスタマイズが必要になる場合があります。そのためには、META-INF/spring-devtools.properties ファイルを作成できます。

spring-devtools.properties ファイルには、restart.exclude および restart.include というプレフィックスが付いたプロパティを含めることができます。include 要素は「再起動」クラスローダーにプルアップする必要があるアイテムであり、exclude 要素は「ベース」クラスローダーにプッシュダウンする必要があるアイテムです。次の例に示すように、プロパティの値はクラスパスに適用される正規表現パターンです。

Properties

restart.exclude.companycommonlibs=/mycorp-common-[\\w\\d-\\.]+\\.jar
restart.include.projectcommon=/mycorp-myproj-[\\w\\d-\\.]+\\.jar

Yaml

restart:
  exclude:
    companycommonlibs: "/mycorp-common-[\\w\\d-\\.]+\\.jar"
  include:
    projectcommon: "/mycorp-myproj-[\\w\\d-\\.]+\\.jar"

すべてのプロパティキーは一意である必要があります。プロパティが restart.include. または restart.exclude. で始まる限り、考慮されます。

クラスパスからのすべての META-INF/spring-devtools.properties がロードされます。プロジェクト内、またはプロジェクトが使用するライブラリ内にファイルをパッケージ化できます。

8.2.7. 既知の制限

再起動機能は、標準の ObjectInputStream を使用してデシリアライズされたオブジェクトではうまく機能しません。データをデシリアライズする必要がある場合は、Spring の ConfigurableObjectInputStream を Thread.currentThread().getContextClassLoader() と組み合わせて使用する必要がある場合があります。

残念ながら、いくつかのサードパーティライブラリは、コンテキストクラスローダーを考慮せずにデシリアライズします。このような問題を見つけた場合は、元の作者に修正を依頼する必要があります。

8.3. LiveReload

spring-boot-devtools モジュールには、リソースが変更されたときにブラウザーのリフレッシュをトリガーするために使用できる LiveReload サーバーが組み込まれています。LiveReload ブラウザー拡張機能は、livereload.com (英語) から Chrome、Firefox、Safari で自由に使用できます。

アプリケーションの実行時に LiveReload サーバーを開始したくない場合は、spring.devtools.livereload.enabled プロパティを false に設定できます。

一度に実行できる LiveReload サーバーは 1 つだけです。アプリケーションを開始する前に、他の LiveReload サーバーが実行されていないことを確認してください。IDE から複数のアプリケーションを起動する場合、最初のアプリケーションのみが LiveReload をサポートしています。

ファイルが変更されたときに LiveReload をトリガーするには、自動再起動を有効にする必要があります。

8.4. グローバル設定

以下のファイルのいずれかを $HOME/.config/spring-boot ディレクトリに追加することにより、グローバル devtools 設定を構成できます。

spring-boot-devtools.properties
spring-boot-devtools.yaml
spring-boot-devtools.yml

これらのファイルに追加されたプロパティはすべて、 devtools を使用するマシン上のすべての Spring Boot アプリケーションに適用されます。例: 常にトリガーファイルを使用するように再起動を構成するには、spring-boot-devtools ファイルに次のプロパティを追加します。

Properties

spring.devtools.restart.trigger-file=.reloadtrigger

Yaml

spring:
  devtools:
    restart:
      trigger-file: ".reloadtrigger"

デフォルトでは、$HOME はユーザーのホームディレクトリです。この場所をカスタマイズするには、SPRING_DEVTOOLS_HOME 環境変数または spring.devtools.home システムプロパティを設定します。

$HOME/.config/spring-boot に devtools 構成ファイルが見つからない場合、$HOME ディレクトリのルートで .spring-boot-devtools.properties ファイルの存在が検索されます。これにより、$HOME/.config/spring-boot の場所をサポートしない古いバージョンの Spring Boot にあるアプリケーションと devtools グローバル構成を共有できます。

プロファイルは、devtools プロパティ / yaml ファイルではサポートされていません。

.spring-boot-devtools.properties でアクティブ化されたプロファイルは、プロファイル固有の構成ファイルのロードには影響しません。YAML ファイルとプロパティファイルの両方で、プロファイル固有のファイル名（spring-boot-devtools-<profile>.properties 形式）と spring.config.activate.on-profile ドキュメントはサポートされていません。

8.4.1. File System Watcher の構成

FileSystemWatcher [GitHub] (英語) は、一定の時間間隔でクラスの変更をポーリングし、事前定義された待機期間を待って、変更がないことを確認することによって機能します。Spring Boot は IDE に完全に依存して、Spring Boot がファイルを読み取れる場所にファイルをコンパイルおよびコピーするため、devtools がアプリケーションを再起動したときに特定の変更が反映されない場合があります。このような問題が常に発生する場合は、spring.devtools.restart.poll-interval および spring.devtools.restart.quiet-period パラメーターを開発環境に適した値に増やしてみてください。

Properties

spring.devtools.restart.poll-interval=2s
spring.devtools.restart.quiet-period=1s

Yaml

spring:
  devtools:
    restart:
      poll-interval: "2s"
      quiet-period: "1s"

監視対象のクラスパスディレクトリが 2 秒ごとにポーリングされて変更が確認され、追加のクラス変更がないことを確認するために 1 秒の待機期間が維持されます。

8.5. リモートアプリケーション

Spring Boot 開発者ツールは、ローカル開発に限定されません。アプリケーションをリモートで実行するときに、いくつかの機能を使用することもできます。リモートサポートはオプトインです。これを有効にするとセキュリティ上のリスクになる可能性があります。信頼できるネットワークで実行している場合、または SSL で保護されている場合にのみ有効にしてください。これらのオプションのいずれも使用できない場合は、DevTools ' リモートサポートを使用しないでください。本番デプロイでサポートを有効にしないでください。

有効にするには、次のように、devtools が再パッケージ化されたアーカイブに含まれていることを確認する必要があります。

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <configuration>
                <excludeDevtools>false</excludeDevtools>
            </configuration>
        </plugin>
    </plugins>
</build>

次に、spring.devtools.remote.secret プロパティを設定する必要があります。重要なパスワードやシークレットと同様に、値は一意で強力で、推測や総当たり攻撃ができないようにする必要があります。

リモート devtools サポートは 2 つの部分で提供されます。接続を受け入れるサーバー側エンドポイントと、IDE で実行するクライアントアプリケーションです。spring.devtools.remote.secret プロパティが設定されると、サーバーコンポーネントは自動的に有効になります。クライアントコンポーネントは手動で起動する必要があります。

リモート devtools は、Spring WebFlux アプリケーションではサポートされていません。

8.5.1. リモートクライアントアプリケーションの実行

リモートクライアントアプリケーションは、IDE 内から実行されるように設計されています。接続するリモートプロジェクトと同じクラスパスで org.springframework.boot.devtools.RemoteSpringApplication を実行する必要があります。アプリケーションの単一の必須引数は、接続先のリモート URL です。

例: Eclipse または Spring Tools を使用していて、Cloud Foundry にデプロイした my-app という名前のプロジェクトがある場合は、次のようにします。

Run メニューから Run Configurations… を選択します。
新しい Java Application 「起動構成」を作成します。
my-app プロジェクトを参照します。
org.springframework.boot.devtools.RemoteSpringApplication をメインクラスとして使用します。
https://myapp.cfapps.io を Program arguments （またはリモートの URL）に追加します。

実行中のリモートクライアントは、次のようになります。

  .   ____          _                                              __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _          ___               _      \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` |        | _ \___ _ __  ___| |_ ___ \ \ \ \
 \\/  ___)| |_)| | | | | || (_| []::::::[]   / -_) '  \/ _ \  _/ -_) ) ) ) )
  '  |____| .__|_| |_|_| |_\__, |        |_|_\___|_|_|_\___/\__\___|/ / / /
 =========|_|==============|___/===================================/_/_/_/
 :: Spring Boot Remote :: 2.6.3

2015-06-10 18:25:06.632  INFO 14938 --- [           main] o.s.b.devtools.RemoteSpringApplication   : Starting RemoteSpringApplication on pwmbp with PID 14938 (/Users/pwebb/projects/spring-boot/code/spring-boot-project/spring-boot-devtools/target/classes started by pwebb in /Users/pwebb/projects/spring-boot/code)
2015-06-10 18:25:06.671  INFO 14938 --- [           main] s.c.a.AnnotationConfigApplicationContext : Refreshing org.springframework.context.annotation.AnnotationConfigApplicationContext@2a17b7b6: startup date [Wed Jun 10 18:25:06 PDT 2015]; root of context hierarchy
2015-06-10 18:25:07.043  WARN 14938 --- [           main] o.s.b.d.r.c.RemoteClientConfiguration    : The connection to http://localhost:8080 is insecure. You should use a URL starting with 'https://'.
2015-06-10 18:25:07.074  INFO 14938 --- [           main] o.s.b.d.a.OptionalLiveReloadServer       : LiveReload server is running on port 35729
2015-06-10 18:25:07.130  INFO 14938 --- [           main] o.s.b.devtools.RemoteSpringApplication   : Started RemoteSpringApplication in 0.74 seconds (JVM running for 1.105)

リモートクライアントは実際のアプリケーションと同じクラスパスを使用しているため、アプリケーションプロパティを直接読み取ることができます。これにより、spring.devtools.remote.secret プロパティが読み取られ、認証のためにサーバーに渡されます。

接続プロトコルとして https:// を使用することを常にお勧めします。これにより、トラフィックが暗号化され、パスワードをインターセプトできなくなります。

プロキシを使用してリモートアプリケーションにアクセスする必要がある場合は、spring.devtools.remote.proxy.host および spring.devtools.remote.proxy.port プロパティを構成します。

8.5.2. リモートアップデート

リモートクライアントは、ローカル再起動と同じ方法でアプリケーションクラスパスの変更を監視します。更新されたリソースはすべてリモートアプリケーションにプッシュされ、（必要な場合）再起動をトリガーします。これは、ローカルにないクラウドサービスを使用する機能を反復する場合に役立ちます。一般的に、リモートの更新と再起動は、完全な再構築とデプロイのサイクルよりもはるかに高速です。

遅い開発環境では、沈黙期間が十分ではなく、クラスの変更がバッチに分割される場合があります。クラス変更の最初のバッチがアップロードされた後、サーバーが再起動されます。サーバーが再起動しているため、次のバッチをアプリケーションに送信できません。

これは通常、一部のクラスのアップロードの失敗に関する RemoteSpringApplication ログの警告と、その結果の再試行によって明示されます。ただし、変更の最初のバッチがアップロードされた後、アプリケーションコードの不整合や再起動の失敗につながる可能性もあります。このような問題が常に発生する場合は、spring.devtools.restart.poll-interval および spring.devtools.restart.quiet-period パラメーターを開発環境に適した値に増やしてみてください。これらのプロパティの設定については、File System Watcher の構成セクションを参照してください。

ファイルは、リモートクライアントが実行されている場合にのみ監視されます。リモートクライアントを開始する前にファイルを変更した場合、そのファイルはリモートサーバーにプッシュされません。

9. 本番用にアプリケーションをパッケージ化する

実行可能 jar は、実動デプロイに使用できます。自己完結型であるため、クラウドベースのデプロイにも最適です。

ヘルス、監査、メトリクス REST または JMX エンドポイントなどの追加の「本番対応」機能については、spring-boot-actuator の追加を検討してください。詳細については、actuator.html を参照してください。

10. 次のステップ

Spring Boot の使用方法と、従うべきいくつかのベストプラクティスを理解する必要があります。これで、特定の Spring Boot の機能の 詳細を学ぶことができます。または、スキップして Spring Boot の「本番対応」の特徴について読むこともできます。

Spring Boot での開発

1. ビルドシステム

1.1. 依存関係管理

1.2. Maven

1.3. Gradle

1.4. Ant

1.5. スターター

2. コードの構造化

2.1. 「デフォルト」パッケージの使用

2.2. メインアプリケーションクラスの特定

3. 構成クラス

3.1. 追加の構成クラスのインポート

3.2. XML 設定のインポート

4. 自動構成

4.1. 自動構成の段階的な置き換え

4.2. 特定の自動構成クラスを無効にする

5. Spring Bean と依存性注入

6. @SpringBootApplication アノテーションの使用

7. アプリケーションを実行する

7.1. IDE から実行する

7.2. パッケージ化されたアプリケーションとして実行する

7.3. Maven プラグインの使用

7.4. Gradle プラグインの使用

7.5. ホットスワップ

8. 開発者ツール

8.1. プロパティのデフォルト

8.2. 自動再起動

8.2.1. 状態評価の変更の記録

8.2.2. リソースを除外する

8.2.3. 追加パスの監視

8.2.4. 再起動を無効にする

8.2.5. トリガーファイルの使用

8.2.6. 再起動クラスローダーのカスタマイズ

8.2.7. 既知の制限

8.3. LiveReload

8.4. グローバル設定

8.4.1. File System Watcher の構成

8.5. リモートアプリケーション

8.5.1. リモートクライアントアプリケーションの実行

8.5.2. リモートアップデート

9. 本番用にアプリケーションをパッケージ化する

10. 次のステップ