为何存在非独立构件？WireMock依赖问题引发的疑问

问题复现 #

初次使用WireMock时遭遇NoClassDefFoundError，以下是可复现的场景：

测试代码 #

import com.github.tomakehurst.wiremock.WireMockServer;
import org.junit.jupiter.api.Test;

public class GenericTest {
    @Test
    void test() {
        new WireMockServer(8090);
    }
}

Maven依赖配置 #

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-test</artifactId>
    <scope>test</scope>
</dependency>

<dependency>
    <groupId>org.wiremock</groupId>
    <artifactId>wiremock</artifactId>
    <version>3.5.1</version>
    <scope>test</scope>
</dependency>

报错信息 #

java.lang.NoClassDefFoundError: org/eclipse/jetty/util/thread/ThreadPool

临时解决方案 #

调试后发现，WireMock核心构件未包含Jetty、Handlebars等依赖，需手动补充：

<!-- 补充Jetty依赖示例 -->
<dependency>
    <groupId>org.eclipse.jetty</groupId>
    <artifactId>jetty-util</artifactId>
    <version>12.0.7</version>
</dependency>

除Jetty外，还需手动添加com.github.jknack.handlebars、com.google.common.cache等依赖。更简便的方式是使用wiremock-standalone构件，该包已包含所有依赖，无需手动配置即可运行。

核心疑问 #

为何不将所有WireMock构件都做成独立版？这类需要手动补充依赖的非独立构件存在哪些优势？

解答 #

非独立构件的设计主要基于以下核心原因：

1. 避免依赖冲突：如果项目本身已引入Jetty、Guava等常用库，独立版的全量依赖可能与现有版本冲突，引发类加载异常或兼容问题。非独立版允许复用项目已有依赖，降低冲突风险。
2. 控制包体积：独立版包含所有依赖，体积通常达几十MB；非独立版仅包含WireMock核心代码，体积小巧。对于已有相关依赖的项目，能有效减少构建产物大小，加快构建与部署速度。
3. 支持按需引入：非独立版可拆分为多个细分模块（如核心功能、扩展插件、监控组件等），用户可根据需求仅引入必要模块，无需为冗余功能负担额外依赖。
4. 兼容现有生态：在Spring Boot等已内置Web容器或通用依赖的项目中，非独立版能更好地融入现有依赖体系，利用项目已配置的依赖版本与环境，避免重复引入带来的冗余。

内容的提问来源于stack exchange，提问作者Powet