3.0.4

1. 使用に関するドキュメント

Spring Cloud CircuitBreaker プロジェクトには、Resilience4J および Spring Retry の実装が含まれています。Spring Cloud に実装された API CircuitBreaker は Spring Cloud Commons に存在します。これらの API の使用に関するドキュメントは Spring Cloud Commons ドキュメントにあります。

1.1. Resilience4J サーキットブレーカーの構成

1.1.1. スターター

Resilience4J 実装には 2 つのスターターがあります。1 つはリアクティブアプリケーション用で、もう 1 つは非リアクティブアプリケーション用です。

  • org.springframework.cloud:spring-cloud-starter-circuitbreaker-resilience4j - 非リアクティブアプリケーション

  • org.springframework.cloud:spring-cloud-starter-circuitbreaker-reactor-resilience4j - リアクティブアプリケーション

1.1.2. 自動構成

spring.cloud.circuitbreaker.resilience4j.enabled を false に設定すると、Resilience4J の自動構成を無効にできます。

1.1.3. デフォルト構成

すべてのサーキットブレーカーにデフォルト構成を提供するには、Resilience4JCircuitBreakerFactory または ReactiveResilience4JCircuitBreakerFactory が渡される Customizer Bean を作成します。configureDefault メソッドを使用して、デフォルト構成を提供できます。

@Bean
public Customizer<Resilience4JCircuitBreakerFactory> defaultCustomizer() {
    return factory -> factory.configureDefault(id -> new Resilience4JConfigBuilder(id)
            .timeLimiterConfig(TimeLimiterConfig.custom().timeoutDuration(Duration.ofSeconds(4)).build())
            .circuitBreakerConfig(CircuitBreakerConfig.ofDefaults())
            .build());
}
リアクティブの例 
@Bean
public Customizer<ReactiveResilience4JCircuitBreakerFactory> defaultCustomizer() {
    return factory -> factory.configureDefault(id -> new Resilience4JConfigBuilder(id)
            .circuitBreakerConfig(CircuitBreakerConfig.ofDefaults())
            .timeLimiterConfig(TimeLimiterConfig.custom().timeoutDuration(Duration.ofSeconds(4)).build()).build());
}
ExecutorService のカスタマイズ

サーキットブレーカーを実行する ExecutorService を設定したい場合は、Resilience4JCircuitBreakerFactory を使用して設定できます。

たとえば、コンテキスト対応の ExecutorService を使用する場合は、次のようにします。

@Bean
public Customizer<ReactiveResilience4JCircuitBreakerFactory> defaultCustomizer() {
    return factory -> {
        ContextAwareScheduledThreadPoolExecutor executor = ContextAwareScheduledThreadPoolExecutor.newScheduledThreadPool().corePoolSize(5)
            .build();
        factory.configureExecutorService(executor);
    };
}

1.1.4. 特定のサーキットブレーカーの構成

デフォルト構成を提供するのと同様に、Customizer Bean を作成できます。これには、Resilience4JCircuitBreakerFactory または ReactiveResilience4JCircuitBreakerFactory が渡されます。

@Bean
public Customizer<Resilience4JCircuitBreakerFactory> slowCustomizer() {
    return factory -> factory.configure(builder -> builder.circuitBreakerConfig(CircuitBreakerConfig.ofDefaults())
            .timeLimiterConfig(TimeLimiterConfig.custom().timeoutDuration(Duration.ofSeconds(2)).build()), "slow");
}

作成されたサーキットブレーカーの設定に加えて、作成された後、発信者に返される前にサーキットブレーカーをカスタマイズすることもできます。これを行うには、addCircuitBreakerCustomizer メソッドを使用できます。これは、Resilience4J サーキットブレーカーにイベントハンドラーを追加する場合に役立ちます。

@Bean
public Customizer<Resilience4JCircuitBreakerFactory> slowCustomizer() {
    return factory -> factory.addCircuitBreakerCustomizer(circuitBreaker -> circuitBreaker.getEventPublisher()
    .onError(normalFluxErrorConsumer).onSuccess(normalFluxSuccessConsumer), "normalflux");
}
リアクティブの例 
@Bean
public Customizer<ReactiveResilience4JCircuitBreakerFactory> slowCustomizer() {
    return factory -> {
        factory.configure(builder -> builder
        .timeLimiterConfig(TimeLimiterConfig.custom().timeoutDuration(Duration.ofSeconds(2)).build())
        .circuitBreakerConfig(CircuitBreakerConfig.ofDefaults()), "slow", "slowflux");
        factory.addCircuitBreakerCustomizer(circuitBreaker -> circuitBreaker.getEventPublisher()
            .onError(normalFluxErrorConsumer).onSuccess(normalFluxSuccessConsumer), "normalflux");
     };
}

1.1.5. サーキットブレーカープロパティの構成

アプリケーションの構成プロパティファイルで、CircuitBreaker および TimeLimiter 構成またはインスタンスを構成できます。プロパティ構成は、Java Customizer 構成よりも優先度が高くなります。

優先順位は上から順。

  • Method(id) config - 特定のメソッドまたは操作について

  • サービス (グループ) 構成 - 特定のアプリケーションサービスまたは操作について

  • グローバルデフォルト設定 

ReactiveResilience4JCircuitBreakerFactory.create(String id, String groupName)
Resilience4JCircuitBreakerFactory.create(String id, String groupName)
グローバルデフォルトプロパティの設定 
resilience4j.circuitbreaker:
    configs:
        default:
            registerHealthIndicator: true
            slidingWindowSize: 50

resilience4j.timelimiter:
    configs:
        default:
            timeoutDuration: 5s
            cancelRunningFuture: true
構成プロパティの構成 
resilience4j.circuitbreaker:
    configs:
        groupA:
            registerHealthIndicator: true
            slidingWindowSize: 200

resilience4j.timelimiter:
    configs:
        groupC:
            timeoutDuration: 3s
            cancelRunningFuture: true
インスタンスプロパティの構成 
resilience4j.circuitbreaker:
 instances:
     backendA:
         registerHealthIndicator: true
         slidingWindowSize: 100
     backendB:
         registerHealthIndicator: true
         slidingWindowSize: 10
         permittedNumberOfCallsInHalfOpenState: 3
         slidingWindowType: TIME_BASED
         recordFailurePredicate: io.github.robwin.exception.RecordFailurePredicate

resilience4j.timelimiter:
 instances:
     backendA:
         timeoutDuration: 2s
         cancelRunningFuture: true
     backendB:
         timeoutDuration: 1s
         cancelRunningFuture: false

  • ReactiveResilience4JCircuitBreakerFactory.create("backendA") または Resilience4JCircuitBreakerFactory.create("backendA") は instances backendA properties を適用します

  • ReactiveResilience4JCircuitBreakerFactory.create("backendA", "groupA") または Resilience4JCircuitBreakerFactory.create("backendA", "groupA") は instances backendA properties を適用します

  • ReactiveResilience4JCircuitBreakerFactory.create("backendC") または Resilience4JCircuitBreakerFactory.create("backendC") は global default properties を適用します

  • ReactiveResilience4JCircuitBreakerFactory.create("backendC", "groupC") または Resilience4JCircuitBreakerFactory.create("backendC", "groupC") は global default CircuitBreaker properties and config groupC TimeLimiter properties を適用します

Resilience4j プロパティ構成の詳細については、Resilience4J Spring Boot 2 の構成 (英語) を参照してください。

1.1.6. バルクヘッドパターン対応

resilience4j-bulkhead がクラスパス上にある場合、Spring Cloud CircuitBreaker はすべてのメソッドを Resilience4j Bulkhead でラップします。spring.cloud.circuitbreaker.bulkhead.resilience4j.enabled を false に設定することで、Resilience4j Bulkhead を無効にできます。

Spring Cloud CircuitBreaker Resilience4j は、バルクヘッドパターンの 2 つの実装を提供します。

  • セマフォを使用する SemaphoreBulkhead 

  • 制限付きキューと固定スレッドプールを使用する FixedThreadPoolBulkhead。

デフォルトでは、Spring Cloud CircuitBreaker Resilience4j は FixedThreadPoolBulkhead を使用します。SemaphoreBulkhead を使用するようにデフォルトの動作を変更するには、プロパティ spring.cloud.circuitbreaker.resilience4j.enableSemaphoreDefaultBulkhead を true に設定します。

バルクヘッドパターンの実装の詳細については、Resilience4j バルクヘッド (英語) を参照してください。

Customizer<Resilience4jBulkheadProvider> を使用して、デフォルトの Bulkhead および ThreadPoolBulkhead 構成を提供できます。

@Bean
public Customizer<Resilience4jBulkheadProvider> defaultBulkheadCustomizer() {
    return provider -> provider.configureDefault(id -> new Resilience4jBulkheadConfigurationBuilder()
        .bulkheadConfig(BulkheadConfig.custom().maxConcurrentCalls(4).build())
        .threadPoolBulkheadConfig(ThreadPoolBulkheadConfig.custom().coreThreadPoolSize(1).maxThreadPoolSize(1).build())
        .build()
);
}

1.1.7. 特定のバルクヘッド構成

デフォルトの「バルクヘッド」または "ThreadPoolBulkhead" 構成を証明するのと同様に、Customizer Bean を作成して、これに Resilience4jBulkheadProvider を渡すことができます。

@Bean
public Customizer<Resilience4jBulkheadProvider> slowBulkheadProviderCustomizer() {
    return provider -> provider.configure(builder -> builder
        .bulkheadConfig(BulkheadConfig.custom().maxConcurrentCalls(1).build())
        .threadPoolBulkheadConfig(ThreadPoolBulkheadConfig.ofDefaults()), "slowBulkhead");
}

作成されたバルクヘッドを構成することに加えて、バルクヘッドとスレッドプールバルクヘッドをカスタマイズしてから、作成してから呼び出し元に戻すこともできます。これを行うには、addBulkheadCustomizer および addThreadPoolBulkheadCustomizer メソッドを使用できます。

バルクヘッドの例 
@Bean
public Customizer<Resilience4jBulkheadProvider> customizer() {
    return provider -> provider.addBulkheadCustomizer(bulkhead -> bulkhead.getEventPublisher()
        .onCallRejected(slowRejectedConsumer)
        .onCallFinished(slowFinishedConsumer), "slowBulkhead");
}
スレッドプールのバルクヘッドの例 
@Bean
public Customizer<Resilience4jBulkheadProvider> slowThreadPoolBulkheadCustomizer() {
    return provider -> provider.addThreadPoolBulkheadCustomizer(threadPoolBulkhead -> threadPoolBulkhead.getEventPublisher()
        .onCallRejected(slowThreadPoolRejectedConsumer)
        .onCallFinished(slowThreadPoolFinishedConsumer), "slowThreadPoolBulkhead");
}

1.1.8. バルクヘッドプロパティの設定

アプリケーションの構成プロパティファイルで ThreadPoolBulkhead および SemaphoreBulkhead インスタンスを構成できます。プロパティ構成は、Java Customizer 構成よりも優先されます。

resilience4j.thread-pool-bulkhead:
    instances:
        backendA:
            maxThreadPoolSize: 1
            coreThreadPoolSize: 1
resilience4j.bulkhead:
    instances:
        backendB:
            maxConcurrentCalls: 10

Resilience4j プロパティ構成の詳細については、Resilience4J Spring Boot 2 の構成 (英語) を参照してください。

1.1.9. 指標の収集

Spring Cloud Circuit Breaker Resilience4j には、適切な依存関係がクラスパスにある限り、メトリクス収集をセットアップするための自動構成が含まれています。メトリクス収集を有効にするには、org.springframework.boot:spring-boot-starter-actuator と io.github.resilience4j:resilience4j-micrometer を含める必要があります。これらの依存関係が存在する場合に生成されるメトリクスの詳細については、Resilience4j のドキュメント (英語) を参照してください。

spring-boot-starter-actuator によってもたらされるため、micrometer-core を直接含める必要はありません。

1.2. Spring Retry サーキットブレーカーの構成

Spring Retry は、Spring アプリケーションの宣言型再試行サポートを提供します。プロジェクトのサブセットには、サーキットブレーカー機能を実装する機能が含まれています。Spring Retry は、CircuitBreakerRetryPolicy (英語) とステートフルリトライの組み合わせにより、サーキットブレーカーの実装を提供します。Spring Retry を使用して作成されたすべてのサーキットブレーカーは、CircuitBreakerRetryPolicy と DefaultRetryState [GitHub] (英語) を使用して作成されます。これらのクラスは両方とも、SpringRetryConfigBuilder を使用して構成できます。

1.2.1. デフォルト構成

すべてのサーキットブレーカーにデフォルト構成を提供するには、SpringRetryCircuitBreakerFactory が渡される Customizer Bean を作成します。configureDefault メソッドを使用して、デフォルト構成を提供できます。

@Bean
public Customizer<SpringRetryCircuitBreakerFactory> defaultCustomizer() {
    return factory -> factory.configureDefault(id -> new SpringRetryConfigBuilder(id)
        .retryPolicy(new TimeoutRetryPolicy()).build());
}

1.2.2. 特定のサーキットブレーカーの構成

デフォルト構成を提供するのと同様に、Customizer Bean を作成できます。これには、SpringRetryCircuitBreakerFactory が渡されます。

@Bean
public Customizer<SpringRetryCircuitBreakerFactory> slowCustomizer() {
    return factory -> factory.configure(builder -> builder.retryPolicy(new SimpleRetryPolicy(1)).build(), "slow");
}

作成されたサーキットブレーカーの設定に加えて、作成された後、発信者に返される前にサーキットブレーカーをカスタマイズすることもできます。これを行うには、addRetryTemplateCustomizers メソッドを使用できます。これは、RetryTemplate にイベントハンドラーを追加する場合に役立ちます。

@Bean
public Customizer<SpringRetryCircuitBreakerFactory> slowCustomizer() {
    return factory -> factory.addRetryTemplateCustomizers(retryTemplate -> retryTemplate.registerListener(new RetryListener() {

        @Override
        public <T, E extends Throwable> boolean open(RetryContext context, RetryCallback<T, E> callback) {
            return false;
        }

        @Override
        public <T, E extends Throwable> void close(RetryContext context, RetryCallback<T, E> callback, Throwable throwable) {

        }

        @Override
        public <T, E extends Throwable> void onError(RetryContext context, RetryCallback<T, E> callback, Throwable throwable) {

        }
    }));
}

2. ビルド

2.1. 基本的なコンパイルとテスト

ソースをビルドするには、JDK17 をインストールする必要があります。

Spring Cloud は、ほとんどのビルド関連のアクティビティに Maven を使用します。関心のあるプロジェクトのクローンを作成して入力することで、非常に迅速に作業を開始できるはずです。

$ ./mvnw install
以下の例では、Maven（> = 3.3.3）を自分でインストールして、./mvnw の代わりに mvn コマンドを実行することもできます。これを行う場合、ローカル Maven 設定に Spring プレリリースアーティファクトのリポジトリ宣言が含まれていない場合は、-P spring も追加する必要があります。
-Xmx512m -XX:MaxPermSize=128m のような値で MAVEN_OPTS 環境変数を設定することにより、Maven で使用可能なメモリの量を増やす必要がある場合があることに注意してください。これは .mvn 構成でカバーしようとしているため、ビルドを成功させるためにそれを行う必要がある場合は、チケットを発行して設定をソース管理に追加してください。

テストにミドルウェア（つまり Redis）を必要とするプロジェクトでは、通常、[Docker]（www.docker.com/get-started (英語) ）のローカルインスタンスがインストールされ、実行されている必要があります。

2.2. ドキュメント

spring-cloud-build モジュールには "docs" プロファイルがあり、これをオンにすると、src/main/asciidoc から asciidoc ソースを構築しようとします。そのプロセスの一部として、README.adoc を探し、すべてのインクルードをロードして処理しますが、解析やレンダリングは行わず、${main.basedir} （デフォルトは $/tmp/releaser-1706275114670-0/spring-cloud-circuitbreaker/docs、つまりプロジェクトのルート）にコピーします。README に変更がある場合は、Maven ビルド後に、変更されたファイルとして正しい場所に表示されます。コミットして変更をプッシュするだけです。

2.3. コードの操作

IDE 設定がない場合は、コードを操作するときに Spring Tools Suite または Eclipse (英語) を使用することをお勧めします。maven サポートには m2eclipseeclipse (英語) プラグインを使用します。他の IDE やツールも、Maven 3.3.3 以上を使用している限り、課題なく動作するはずです。

2.3.1. Spring Maven プロファイルをアクティブ化する

Spring Cloud プロジェクトでは、Spring のマイルストーンとスナップショットリポジトリを解決するために、"Spring" の Maven プロファイルをアクティブ化する必要があります。推奨する IDE を使用して、このプロファイルをアクティブに設定してください。そうしないと、ビルドエラーが発生する可能性があります。

2.3.2. m2eclipse を使用して Eclipse にインポートする

Eclipse を使用する場合は、m2eclipseeclipse (英語) プラグインをお勧めします。m2eclipse をまだインストールしていない場合は、"eclipsemarketplace" から入手できます。

古いバージョンの m2e は Maven 3.3 をサポートしていないため、プロジェクトを Eclipse にインポートしたら、プロジェクトに適切なプロファイルを使用するように m2eclipse に指示する必要もあります。プロジェクトの POM に関連するさまざまなエラーが表示される場合は、インストールが最新であることを確認してください。m2e をアップグレードできない場合は、settings.xml に "Spring" プロファイルを追加してください。または、親 pom の "Spring" プロファイルから settings.xml にリポジトリ設定をコピーすることもできます。

2.3.3. m2eclipse なしで Eclipse にインポートする

m2eclipse を使用したくない場合は、次のコマンドを使用して Eclipse プロジェクトのメタデータを生成できます。

$ ./mvnw eclipse:eclipse

生成された日食プロジェクトは、file メニューから import existing projects を選択することでインポートできます。

3. コントリビュートする

Spring Cloud は、制限のない Apache 2.0 ライセンスでリリースされており、課題には Github トラッカーを使用し、プルリクエストをマスターにマージする、非常に標準的な Github 開発プロセスに従っています。些細なことでも貢献したい場合は、遠慮なく以下のガイドラインに従ってください。

3.1. コントリビューターライセンス契約に署名する

重要なパッチまたはプルリクエストを受け入れる前に、コントリビューターライセンス契約 (英語) に署名する必要があります。コントリビューターの契約に署名しても、メインリポジトリへのコミット権は誰にも付与されませんが、あなたのコントリビュートを受け入れることができることを意味し、そうすれば作成者のクレジットを取得します。アクティブなコントリビューターは、コアチームに参加するように求められ、プルリクエストをマージする機能が与えられる場合があります。

3.2. 行動規範

このプロジェクトは、ContributorCovenant の行動規範 [GitHub] (英語) に準拠しています。参加することにより、この規範を支持することが期待されます。許容できない動作を [ メール保護 ] (英語) に報告してください。

3.3. コード規約とハウスキーピング

これらはいずれもプルリクエストに必須ではありませんが、すべて役に立ちます。これらは、元のプルリクエストの後、マージの前に追加することもできます。

  • Spring Framework コード形式の規則を使用してください。Eclipse を使用する場合は、Spring Cloud Build (英語) プロジェクトから eclipse-code-formatter.xml ファイルを使用してフォーマッター設定をインポートできます。IntelliJ を使用している場合は、Eclipse コードフォーマッタープラグイン (英語) を使用して同じファイルをインポートできます。

  • すべての新しい .java ファイルに、少なくともあなたを識別する @author タグ、できればクラスの目的に関する段落を含む単純な Javadoc クラスコメントが含まれていることを確認してください。

  • ASF ライセンスヘッダーコメントをすべての新しい .java ファイルに追加します (プロジェクト内の既存のファイルからコピーする)

  • 大幅に変更する .java ファイルに @author として自分自身を追加します（外観上の変更以上のもの）。

  • いくつかの Javadoc を追加し、名前空間を変更する場合は、いくつかの XSDdoc 要素を追加します。

  • いくつかの単体テストも大いに役立ちます。誰かがそれをしなければなりません。

  • 他の誰もブランチを使用していない場合は、現在のマスター（またはメインプロジェクトの他のターゲットブランチ）に対してリベースしてください。

  • コミットメッセージを作成するときは、次の規則 (英語) に従ってください。既存の課題を修正する場合は、コミットメッセージの最後に Fixes gh-XXXX を追加してください（XXXX は課題番号です）。

3.4. Checkstyle

Spring Cloud Build には、一連の checkstyle ルールが付属しています。これらは spring-cloud-build-tools モジュールにあります。モジュール内の最も注目すべきファイルは次のとおりです。

spring-cloud-build-tools/
└── src
    ├── checkstyle
    │   └── checkstyle-suppressions.xml (3)
    └── main
        └── resources
            ├── checkstyle-header.txt (2)
            └── checkstyle.xml (1)
1 デフォルトの Checkstyle ルール
2 ファイルヘッダーの設定
3 デフォルトの抑制ルール

3.4.1. Checkstyle 構成

Checkstyle ルールはデフォルトで無効になっています。プロジェクトに checkstyle を追加するには、次のプロパティとプラグインを定義するだけです。

pom.xml
<properties>
<maven-checkstyle-plugin.failsOnError>true</maven-checkstyle-plugin.failsOnError> (1)
        <maven-checkstyle-plugin.failsOnViolation>true
        </maven-checkstyle-plugin.failsOnViolation> (2)
        <maven-checkstyle-plugin.includeTestSourceDirectory>true
        </maven-checkstyle-plugin.includeTestSourceDirectory> (3)
</properties>

<build>
        <plugins>
            <plugin> (4)
                <groupId>io.spring.javaformat</groupId>
                <artifactId>spring-javaformat-maven-plugin</artifactId>
            </plugin>
            <plugin> (5)
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-checkstyle-plugin</artifactId>
            </plugin>
        </plugins>

    <reporting>
        <plugins>
            <plugin> (5)
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-checkstyle-plugin</artifactId>
            </plugin>
        </plugins>
    </reporting>
</build>
1Checkstyle エラー時にビルドに失敗する
2Checkstyle 違反でビルドに失敗する
3Checkstyle はテストソースも分析します
4Checkstyle フォーマットルールのほとんどに合格するようにコードを再フォーマットする Spring Java フォーマットプラグインを追加します
5checkstyle プラグインをビルドフェーズとレポートフェーズに追加します

一部のルールを抑制する必要がある場合（たとえば、行の長さを長くする必要がある場合）、抑制を使用して ${project.root}/src/checkstyle/checkstyle-suppressions.xml でファイルを定義するだけで十分です。例:

projectRoot/src/checkstyle/checkstyle-suppresions.xml
<?xml version="1.0"?>
<!DOCTYPE suppressions PUBLIC
        "-//Puppy Crawl//DTD Suppressions 1.1//EN"
        "https://www.puppycrawl.com/dtds/suppressions_1_1.dtd">
<suppressions>
    <suppress files=".*ConfigServerApplication\.java" checks="HideUtilityClassConstructor"/>
    <suppress files=".*ConfigClientWatch\.java" checks="LineLengthCheck"/>
</suppressions>

${spring-cloud-build.rootFolder}/.editorconfig と ${spring-cloud-build.rootFolder}/.springformat をプロジェクトにコピーすることをお勧めします。そうすれば、いくつかのデフォルトのフォーマットルールが適用されます。これを行うには、次のスクリプトを実行します。

$ curl https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/master/.editorconfig -o .editorconfig
$ touch .springformat

3.5. IDE のセットアップ

3.5.1. Intellij IDEA

Intellij をセットアップするには、コーディング規約であるインスペクションプロファイルをインポートし、checkstyle プラグインをセットアップする必要があります。次のファイルは Spring Cloud Build [GitHub] (英語) プロジェクトにあります。

spring-cloud-build-tools/
└── src
    ├── checkstyle
    │   └── checkstyle-suppressions.xml (3)
    └── main
        └── resources
            ├── checkstyle-header.txt (2)
            ├── checkstyle.xml (1)
            └── intellij
                ├── Intellij_Project_Defaults.xml (4)
                └── Intellij_Spring_Boot_Java_Conventions.xml (5)
1 デフォルトの Checkstyle ルール
2 ファイルヘッダーの設定
3 デフォルトの抑制ルール
4Checkstyle ルールのほとんどを適用する Intellij のプロジェクトのデフォルト
5Checkstyle ルールのほとんどを適用する Intellij のプロジェクトスタイルの規則
Code style
図 1: コードスタイル

File → Settings → Editor → Code style に移動します。Scheme セクションの横にあるアイコンをクリックします。そこで、Import Scheme 値をクリックして、Intellij IDEA code style XML オプションを選択します。spring-cloud-build-tools/src/main/resources/intellij/Intellij_Spring_Boot_Java_Conventions.xml ファイルをインポートします。

Code style
図 2: インスペクションプロファイル

File → Settings → Editor → Inspections に移動します。Profile セクションの横にあるアイコンをクリックします。そこで、Import Profile をクリックして、spring-cloud-build-tools/src/main/resources/intellij/Intellij_Project_Defaults.xml ファイルをインポートします。

Checkstyle

Intellij を Checkstyle で動作させるには、Checkstyle プラグインをインストールする必要があります。JUnit アサーションを自動的に変換するために Assertions2Assertj もインストールすることをお勧めします

Checkstyle

File → Settings → Other settings → Checkstyle に進みます。Configuration file セクションの + アイコンをクリックします。そこで、checkstyle ルールをどこから選択するかを定義する必要があります。上のイメージでは、複製された Spring Cloud Build リポジトリからルールを選択しています。ただし、Spring Cloud Build の GitHub リポジトリを指定することはできます (例: checkstyle.xml : raw.githubusercontent.com/spring-cloud/spring-cloud-build/master/spring-cloud-build-tools/src/main/resources/checkstyle.xml (英語) )。次の変数を指定する必要があります。

本番ソースとテストソースに checkstyle ルールを適用するため、Scan Scope を All sources に設定することを忘れないでください。

3.6. 重複ファインダー

Spring Cloud Build には basepom:duplicate-finder-maven-plugin が組み込まれており、これにより、java クラスパス上の重複および競合するクラスとリソースにフラグを立てることができます。

3.6.1. Finder 構成の複製

重複ファインダーはデフォルトで有効になっており、Maven ビルドの verify フェーズで実行されますが、プロジェクトで duplicate-finder-maven-plugin をプロジェクトの pom.xml の build セクションに追加した場合にのみ有効になります。

pom.xml
<build>
    <plugins>
        <plugin>
            <groupId>org.basepom.maven</groupId>
            <artifactId>duplicate-finder-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

その他のプロパティについては、プラグインのドキュメント [GitHub] (英語) に記載されているデフォルトを設定しています。

それらは簡単にオーバーライドできますが、duplicate-finder-maven-plugin のプレフィックスが付いた選択したプロパティの値を設定します。例: ビルドでの重複チェックをスキップするには、duplicate-finder-maven-plugin.skip を true に設定します。

ignoredClassPatterns または ignoredResourcePatterns をセットアップに追加する必要がある場合は、プロジェクトのプラグイン構成セクションに必ず追加してください。

<build>
    <plugins>
        <plugin>
            <groupId>org.basepom.maven</groupId>
            <artifactId>duplicate-finder-maven-plugin</artifactId>
            <configuration>
                <ignoredClassPatterns>
                    <ignoredClassPattern>org.joda.time.base.BaseDateTime</ignoredClassPattern>
                    <ignoredClassPattern>.*module-info</ignoredClassPattern>
                </ignoredClassPatterns>
                <ignoredResourcePatterns>
                    <ignoredResourcePattern>changelog.txt</ignoredResourcePattern>
                </ignoredResourcePatterns>
            </configuration>
        </plugin>
    </plugins>
</build>