本文介绍一种将插件 jar 及其完整依赖树独立打包、按目录隔离部署到 docker 镜像中的构建方案，避免插件被合并进 spring boot uber jar，从而支持运行时独立 classloader 加载。
本文介绍一种将插件 jar 及其完整依赖树独立打包、按目录隔离部署到 docker 镜像中的构建方案，避免插件被合并进 spring boot uber jar，从而支持运行时独立 classloader 加载。
要实现插件服务器的真正模块化与动态加载能力，关键在于解耦构建时依赖与运行时类加载边界：插件不应作为编译/打包期的 compile 或 runtime 依赖参与主服务的构建，而应以“可插拔资源”形式在构建后期被收集、展开并分目录部署。
✅ 正确的构建策略
从主服务 POM 中移除所有插件依赖
将块中所有插件（如 plugin-a, plugin-b）及其传递依赖全部删除。主服务仅保留核心框架（Spring Boot、日志、配置等），确保最终生成的 server.jar 是纯净的、不含任何插件字节码的可执行包。 为插件定义独立的 assembly.xml
在项目根目录或 plugins/ 子模块下创建 src/assembly/plugins.xml，使用 Maven Assembly Plugin 按插件维度拉取并展开每个插件及其完整依赖树：
<!-- src/assembly/plugins.xml --> <assembly xmlns="http://maven.apache.org/ASSEMBLY/2.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemalocation="http://maven.apache.org/ASSEMBLY/2.0.0 http://maven.apache.org/xsd/assembly-2.0.0.xsd"><id>plugins</id><formats><format>dir</format></formats><includebasedirectory>false</includebasedirectory><!-- plugin-a 及其所有依赖 --><dependencysets><dependencyset><outputdirectory>plugin-a</outputdirectory><includes><include>com.example:plugin-a</include></includes><useprojectartifact>false</useprojectartifact><unpack>true</unpack><scope>runtime</scope><usetransitivedependencies>true</usetransitivedependencies></dependencyset><!-- plugin-b 及其所有依赖 --><dependencyset><outputdirectory>plugin-b</outputdirectory><includes><include>com.example:plugin-b</include></includes><useprojectartifact>false</useprojectartifact><unpack>true</unpack><scope>runtime</scope><usetransitivedependencies>true</usetransitivedependencies></dependencyset></dependencysets></assembly>
⚠️ 注意：
true 会解压 JAR 内容（含 META-INF/, classes/, lib/ 等），便于 JVM URLClassLoader 直接加载整个目录；若需保留 JAR 形式，改用false 并配合手动复制 JAR + lib/ 目录。
-
绑定 Assembly 到构建生命周期
在主 pom.xml 中配置插件：
<plugin><groupid>org.apache.maven.plugins</groupid><artifactid>maven-assembly-plugin</artifactid><version>3.6.0</version><executions><execution><id>make-plugins-dir</id><phase>package</phase><goals><goal>single</goal></goals><configuration><descriptors><descriptor>src/assembly/plugins.xml</descriptor></descriptors><finalname>plugins</finalname><appendassemblyid>false</appendassemblyid></configuration></execution></executions></plugin>
执行 mvn clean package 后，将在 target/plugins/ 下生成结构清晰的插件目录树：
target/plugins/ ├── plugin-a/ │ ├── com.example.plugin-a-1.2.0.jar │ ├── lib/ │ │ ├── guava-32.1.3-jre.jar │ │ └── jackson-databind-2.15.2.jar ├── plugin-b/ │ ├── com.example.plugin-b-0.9.1.jar │ └── lib/ │ └── commons-lang3-3.12.0.jar
? Docker 构建适配
在 Dockerfile 中，将插件目录作为独立层 COPY 进镜像，并确保启动脚本能识别该路径：
FROM openjdk:17-jre-slim # 复制主服务 JAR（纯净版） COPY target/server.jar /app/server.jar # 复制插件目录（利用 Docker layer cache，插件变更不影响基础镜像） COPY target/plugins /app/plugins ENTRYPOINT ["java", "-Dplugin.dir=/app/plugins", "-jar", "/app/server.jar"]
服务启动时，可通过 System.getProperty("plugin.dir") 获取路径，用 File.toURI() 构造 URL[]，再创建 URLClassLoader 分别加载各插件目录，实现完全隔离的类加载域。
✅ 总结
- 插件必须从主 POM 移除，杜绝“隐式依赖污染”；
- 使用 maven-assembly-plugin + unpack=true + useTransitiveDependencies=true 是精准提取插件全依赖树的核心手段；
- Docker 层级分离（server.jar vs plugins/）提升可维护性与部署灵活性；
- 运行时需配合自定义 ClassLoader 策略（推荐 URLClassLoader 或 LaunchedURLClassLoader 的封装），确保类隔离与热替换可行性。
此架构为微内核（Microkernel）式插件系统提供了坚实的构建基础设施支撑。
