3.0.4

1. 使用文件

Spring Cloud CircuitBreaker 專案包含 Resilience4J 和 Spring Retry 的實作。Spring Cloud CircuitBreaker 中實作的 API 位於 Spring Cloud Commons 中。這些 API 的使用文件位於 Spring Cloud Commons 文件中。

1.1. 配置 Resilience4J 斷路器

1.1.1. 啟動器

Resilience4J 實作有兩個啟動器，一個用於反應式應用程式，另一個用於非反應式應用程式。

  • 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. 預設配置

若要為所有斷路器提供預設配置，請建立一個 Customizer Bean，並傳遞 Resilience4JCircuitBreakerFactory 或 ReactiveResilience4JCircuitBreakerFactory。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 來完成。

例如，如果您想要使用 context aware 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) 配置 - 針對特定方法或操作

  • Service(group) 配置 - 針對特定應用程式服務或操作

  • 全域預設配置

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
Configs 屬性配置
resilience4j.circuitbreaker:
    configs:
        groupA:
            registerHealthIndicator: true
            slidingWindowSize: 200

resilience4j.timelimiter:
    configs:
        groupC:
            timeoutDuration: 3s
            cancelRunningFuture: true
Instances 屬性配置
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 屬性

  • ReactiveResilience4JCircuitBreakerFactory.create("backendA", "groupA") 或 Resilience4JCircuitBreakerFactory.create("backendA", "groupA") 將套用 instances backendA 屬性

  • ReactiveResilience4JCircuitBreakerFactory.create("backendC") 或 Resilience4JCircuitBreakerFactory.create("backendC") 將套用 全域預設屬性

  • ReactiveResilience4JCircuitBreakerFactory.create("backendC", "groupC") 或 Resilience4JCircuitBreakerFactory.create("backendC", "groupC") 將套用 全域預設 CircuitBreaker 屬性和 config groupC TimeLimiter 屬性

有關 Resilience4j 屬性配置的更多資訊，請參閱 Resilience4J Spring Boot 2 配置。

1.1.6. 艙壁模式支援

如果 resilience4j-bulkhead 在類別路徑上，Spring Cloud CircuitBreaker 將使用 Resilience4j 艙壁包裝所有方法。您可以將 spring.cloud.circuitbreaker.bulkhead.resilience4j.enabled 設定為 false 來停用 Resilience4j 艙壁。

Spring Cloud CircuitBreaker Resilience4j 提供艙壁模式的兩種實作

  • 一個使用訊號量的 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. 特定艙壁配置

與證明預設 'Bulkhead' 或 '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 文件。

您不必直接包含 micrometer-core，因為它是由 spring-boot-starter-actuator 引入的

1.2. 配置 Spring Retry 斷路器

Spring Retry 為 Spring 應用程式提供宣告式重試支援。專案的子集包含實作斷路器功能的能力。Spring Retry 透過其 CircuitBreakerRetryPolicy 和 stateful retry 的組合提供斷路器實作。使用 Spring Retry 建立的所有斷路器都將使用 CircuitBreakerRetryPolicy 和 DefaultRetryState 建立。這兩個類別都可以使用 SpringRetryConfigBuilder 進行配置。

1.2.1. 預設配置

若要為所有斷路器提供預設配置，請建立一個 Customizer Bean，並傳遞 SpringRetryCircuitBreakerFactory。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. 基本編譯與測試

若要建置來源程式碼，您需要安裝 JDK 17。

Spring Cloud 對於大多數建置相關活動使用 Maven，您應該能夠透過複製您感興趣的專案並輸入以下內容來快速開始：

$ ./mvnw install
您也可以自行安裝 Maven (>=3.3.3) 並在範例中使用 mvn 命令取代 ./mvnw。如果您這樣做，如果您的本機 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" profile，如果您開啟它，它將嘗試從 src/main/asciidoc 建置 asciidoc 來源。作為該過程的一部分，它將尋找 README.adoc 並透過載入所有 include 來處理它，但不解析或呈現它，只是將其複製到 ${main.basedir}（預設為 $/tmp/releaser-1706275114670-0/spring-cloud-circuitbreaker/docs，即專案的根目錄）。如果 README 中有任何變更，則在 Maven 建置之後，它將顯示為正確位置的已修改檔案。只需提交並推送變更即可。

2.3. 使用程式碼

如果您沒有 IDE 偏好，我們建議您在使用程式碼時使用 Spring Tools Suite 或 Eclipse。我們使用 m2eclipse eclipse 外掛程式來支援 Maven。其他 IDE 和工具也應該可以正常運作，只要它們使用 Maven 3.3.3 或更高版本即可。

2.3.1. 啟用 Spring Maven Profile

Spring Cloud 專案需要啟用 'spring' Maven profile 才能解析 Spring 里程碑和快照儲存庫。使用您偏好的 IDE 將此 profile 設定為啟用，否則您可能會遇到建置錯誤。

2.3.2. 使用 m2eclipse 匯入 Eclipse

我們建議在使用 Eclipse 時使用 m2eclipse eclipse 外掛程式。如果您尚未安裝 m2eclipse，可以從 "eclipse marketplace" 取得。

舊版本的 m2e 不支援 Maven 3.3，因此一旦專案匯入 Eclipse，您還需要告訴 m2eclipse 為專案使用正確的 profile。如果您在專案中看到許多與 POM 相關的不同錯誤，請檢查您是否已安裝最新版本。如果您無法升級 m2e，請將 "spring" profile 新增至您的 settings.xml。或者，您可以將儲存庫設定從父 pom 的 "spring" profile 複製到您的 settings.xml。

2.3.3. 不使用 m2eclipse 匯入 Eclipse

如果您不想使用 m2eclipse，您可以使用以下命令產生 eclipse 專案中繼資料

$ ./mvnw eclipse:eclipse

可以透過從 file 選單中選取 import existing projects 來匯入產生的 eclipse 專案。

3. 貢獻

Spring Cloud 是在非限制性的 Apache 2.0 授權下發布的，並且遵循非常標準的 Github 開發流程，使用 Github tracker 來處理 issue 並將 pull request 合併到 master 中。如果您想貢獻一些即使是很小的東西，請不要猶豫，但請遵循以下準則。

3.1. 簽署貢獻者授權協議

在我們接受重要的補丁或 pull request 之前，我們需要您簽署 貢獻者授權協議。簽署貢獻者協議不會授予任何人對主要儲存庫的 commit 權限，但這確實意味著我們可以接受您的貢獻，如果您這樣做，您將獲得作者署名。活躍的貢獻者可能會被邀請加入核心團隊，並被授予合併 pull request 的能力。

3.2. 行為準則

此專案遵守 Contributor Covenant 行為準則。透過參與，您應該遵守此準則。請向 [email protected] 報告不可接受的行為。

3.3. 程式碼慣例與整理

以下這些對於 pull request 並非必要，但它們都會有所幫助。它們也可以在原始 pull request 之後但在合併之前新增。

  • 使用 Spring Framework 程式碼格式慣例。如果您使用 Eclipse，您可以使用來自 Spring Cloud Build 專案的 eclipse-code-formatter.xml 檔案匯入格式器設定。如果使用 IntelliJ，您可以使用 Eclipse Code Formatter Plugin 外掛程式匯入相同的檔案。

  • 確保所有新的 .java 檔案都有一個簡單的 Javadoc 類別註解，其中至少包含一個識別您的 @author 標籤，最好至少有一個段落說明該類別的用途。

  • 將 ASF 授權標頭註解新增至所有新的 .java 檔案（從專案中的現有檔案複製）

  • 將自己新增為您大幅修改的 .java 檔案的 @author（變更超過外觀）。

  • 新增一些 Javadoc，如果您變更命名空間，則新增一些 XSD 文件元素。

  • 一些單元測試也會有很大幫助 — 總得有人做。

  • 如果沒有其他人使用您的分支，請將其 rebase 到目前的 master（或主要專案中的其他目標分支）。

  • 撰寫 commit 訊息時，請遵循 這些慣例，如果您正在修正現有的 issue，請在 commit 訊息的末尾新增 Fixes gh-XXXX（其中 XXXX 是 issue 編號）。

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>
1 Checkstyle 錯誤時建置失敗
2 Checkstyle 違規時建置失敗
3 Checkstyle 也會分析測試來源
4 新增 Spring Java Format 外掛程式，該外掛程式將重新格式化您的程式碼以通過大多數 Checkstyle 格式規則
5 將 checkstyle 外掛程式新增至您的建置和報告階段

如果您需要抑制某些規則（例如，行長度需要更長），那麼您只需在 ${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，您應該匯入我們的程式碼慣例、檢查 profile 並設定 checkstyle 外掛程式。以下檔案可以在 Spring Cloud Build 專案中找到。

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 預設抑制規則
4 適用於大多數 Checkstyle 規則的 Intellij 專案預設值
5 適用於大多數 Checkstyle 規則的 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. 檢查 Profile

前往 File → Settings → Editor → Inspections。在那裡，按一下 Profile 區段旁邊的圖示。在那裡，按一下 Import Profile 並匯入 spring-cloud-build-tools/src/main/resources/intellij/Intellij_Project_Defaults.xml 檔案。

Checkstyle

為了讓 Intellij 與 Checkstyle 搭配使用，您必須安裝 Checkstyle 外掛程式。建議也安裝 Assertions2Assertj 以自動轉換 JUnit assertions

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）。我們需要提供以下變數

請記住將 Scan Scope 設定為 All sources，因為我們將 checkstyle 規則應用於生產和測試來源。

3.6. 重複檔案偵測器

Spring Cloud Build 引入了 basepom:duplicate-finder-maven-plugin，它可以標記 java 類別路徑上的重複和衝突類別和資源。

3.6.1. 重複檔案偵測器配置

重複檔案偵測器預設為啟用，將在 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>

對於其他屬性，我們已設定預設值，如 外掛程式文件中所列。

您可以輕鬆地覆寫它們，方法是設定以 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>