拓冰网站优化 
1. 项目概述为什么我们需要深入理解POM与打包如果你用Maven开发Java项目超过三个月还在对着pom.xml文件里那些标签感到困惑或者每次打包部署时都祈祷不要出错那这篇文章就是为你准备的。我见过太多项目pom.xml写得像天书依赖冲突、打包失败、部署后类找不到等问题层出不穷最后花在排查上的时间比写业务代码还多。pom.xml远不止是一个依赖声明文件它是Maven项目的“大脑”和“蓝图”定义了项目的身份、结构、行为以及最终产物的形态。而打包Packaging则是将这个蓝图变为可交付成果的最终工序两者结合共同决定了你的项目能否健康构建、顺利部署和稳定运行。简单来说pom.xml负责“想清楚”打包负责“做出来”。但“想清楚”本身就有很多门道依赖版本怎么管理才不冲突多模块项目结构怎么设计不同环境开发、测试、生产的配置如何隔离同样“做出来”也有多种选择打一个可执行的胖JarFat Jar还是打一个包含依赖的War包部署到容器亦或是构建一个包含所有模块的聚合包这些决策都深深烙印在pom.xml的配置和打包生命周期的执行过程中。本文将从一个资深开发者的视角彻底拆解pom.xml的核心元素与打包机制的每一个细节。我不会只罗列标签含义而是结合大量实战中踩过的坑和总结的最佳实践告诉你每个配置项背后的设计意图、常见误区以及如何根据你的项目实际情况做出最优选择。无论你是刚接触Maven的新手还是希望优化现有项目构建流程的老手都能从这里获得可以直接“抄作业”的配置方案和避坑指南。2. POM文件核心架构与设计哲学2.1 POM的本质项目对象模型POMProject Object Model是Maven工作的核心。你可以把它理解为一个项目的“身份证”加“说明书”。它采用XML格式不仅仅是为了人类可读更重要的是机器可解析。Maven通过读取POM文件能精确地知道这个项目是谁坐标、它由什么构成依赖、它要做什么构建生命周期、以及它最终要变成什么样子打包。一个最基本的pom.xml必须包含Maven的模型版本、项目坐标GAV和打包类型。坐标是Maven世界的唯一标识由groupId组织或公司域名的反写如com.example、artifactId项目名如my-app和version版本号如1.0.0-SNAPSHOT组成。packaging默认为jar也可以是war,pom,maven-plugin等。但一个健壮的项目POM远不止这些。它通常包含以下几个关键部分父POM继承通过parent指定一个父项目继承其通用配置如依赖管理、插件配置、仓库地址这是实现多模块项目统一管理和企业级规范的基础。依赖声明在dependencies内声明项目所需的所有库。这里的关键是理解scope作用域和optional可选依赖的用法。依赖管理在dependencyManagement中统一定义依赖及其版本子模块引用时无需指定版本实现了版本的集中管控。构建配置在build中配置资源过滤、插件及其执行目标。这是控制打包行为最核心的区域。属性定义在properties中定义变量如Java版本、依赖版本号实现一处修改处处生效。环境与配置使用profiles为不同环境如dev, test, prod定义不同的配置和构建行为。注意不要在一个简单的单模块项目中过度设计滥用dependencyManagement和profiles会增加复杂度。但当项目规模增长或变为多模块时这些设计会显得至关重要。2.2 依赖管理从混乱到秩序的艺术依赖管理是POM中最容易出问题的地方。很多项目初期依赖随意添加后期冲突不断。一个清晰的依赖管理策略应遵循以下原则1. 作用域Scope的精准使用compile默认值。对编译、测试、运行都有效会打包。provided编译和测试时需要但运行时由容器或JDK提供如Servlet API。不会打包。runtime编译时不需要但测试和运行时需要如JDBC驱动。会打包。test仅用于测试编译和运行阶段。不会打包。system与provided类似但需通过systemPath显式指定本地路径。尽量避免使用因为它破坏了Maven的可移植性。2. 依赖传递与冲突解决 Maven会自动解析传递性依赖。当不同路径引入同一个依赖的不同版本时Maven遵循“最近定义优先”和“第一声明优先”原则。但这常常导致不可预知的行为。最佳实践是使用dependencyManagement在顶层POM中锁定所有常用依赖的版本子模块引用时无需写版本号从根本上杜绝冲突。3. 排除不需要的传递依赖 有时某个依赖会传递引入你不需要或有冲突的库。可以使用exclusions标签将其排除。dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId exclusions exclusion groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-tomcat/artifactId /exclusion /exclusions /dependency4. 使用BOM统一版本 对于Spring Boot、Apache Camel这类大型框架它们会提供BOMBill Of Materials项目。在dependencyManagement中引入BOM可以一键统一所有相关组件的版本确保兼容性。dependencyManagement dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-dependencies/artifactId version2.7.18/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement实操心得我习惯在项目根目录建立一个独立的bom模块专门管理所有第三方依赖的版本。所有业务模块都继承自这个BOM模块。当需要升级某个库比如Log4j2时我只需要修改BOM模块中的一个版本号所有子模块在下次构建时就会自动更新极大降低了升级成本和风险。2.3 多模块项目POM设计实战当业务复杂后单模块项目会变得臃肿。合理的多模块拆分能提高构建速度、明确职责边界、便于团队协作。一个典型的多模块项目结构如下parent-pom (packaging: pom) ├── bom (packaging: pom) - 依赖版本管理 ├── common (packaging: jar) - 通用工具、常量、异常 ├── domain (packaging: jar) - 领域模型、接口 ├── service (packaging: jar) - 业务逻辑实现 ├── web-api (packaging: jar) - 控制器、DTO └── application (packaging: jar) - 启动模块依赖上述模块并打包父POMparent-pom的职责定义modules列出所有子模块。定义公共属性如Java版本、源码编码、项目版本。配置所有子模块共用的插件如编译器插件、源码打包插件。不定义dependencies只定义dependencyManagement。子模块POM的写法通过parent指向父POM。只需声明本模块特有的依赖版本从父POM的dependencyManagement中继承。可以覆盖父POM中定义的属性谨慎使用。一个常见的坑子模块之间循环依赖。例如service模块依赖web-api而web-api又反过来依赖service。这会导致Maven无法确定构建顺序。解决方法是重新审视模块划分将公共部分提取到common或domain模块中确保依赖关系是单向的、有层次的。3. Maven生命周期与打包核心原理3.1 深入理解三套生命周期Maven的生命周期Lifecycle是理解打包如何发生的关键。它包含三套相互独立的生命周期每套生命周期由一系列阶段Phase组成clean清理生命周期包含pre-clean,clean,post-clean阶段。mvn clean会删除target目录。default核心构建生命周期包含编译、测试、打包、安装、部署等关键阶段。这是我们最常打交道的。site站点文档生命周期用于生成项目报告和站点文档。重点在于default生命周期其核心阶段顺序如下validate验证项目是否正确POM是否有效。compile编译项目主源代码。test-compile编译测试源代码。test使用合适的单元测试框架运行测试。package将编译后的代码打包成可分发格式如JAR、WAR。这是打包的核心动作发生阶段。verify对集成测试结果进行检查确保质量达标。install将包安装到本地Maven仓库供本地其他项目依赖。deploy将最终的包复制到远程仓库供其他开发者和项目使用。关键理解当你执行mvn package时Maven会按顺序执行从validate到package的所有阶段。每个阶段背后都绑定了一个或多个插件目标Plugin Goal来具体执行任务。例如package阶段绑定了maven-jar-plugin:jar目标对于打包类型为jar的项目。3.2 插件生命周期背后的执行引擎生命周期阶段是“做什么”插件Plugin是“怎么做”。Maven本身几乎不做任何具体工作所有工作都委托给插件完成。插件配置示例控制如何打Jar包。build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId version3.3.0/version configuration !-- 指定生成的Jar包中包含MANIFEST.MF文件的主类 -- archive manifest mainClasscom.example.Application/mainClass !-- 添加类路径使Jar包能引用依赖的Jar -- addClasspathtrue/addClasspath classpathPrefixlib//classpathPrefix /manifest /archive !-- 排除某些文件不打进Jar包 -- excludes exclude**/*.properties/exclude /excludes /configuration !-- 可以将插件目标绑定到生命周期的特定阶段 -- executions execution phasepackage/phase goals goaljar/goal /goals /execution /executions /plugin /plugins /build插件管理和依赖管理类似可以在父POM中使用pluginManagement统一管理插件的版本和基础配置子模块只需引用插件而无需重复配置版本。实操心得对于Spring Boot项目我们通常使用spring-boot-maven-plugin来打包它会生成一个可执行的、包含所有依赖的“胖Jar”。但有时你可能需要同时生成一个普通的Jar给其他项目依赖和一个可执行的胖Jar。这时可以配置该插件绑定到package阶段同时配置maven-jar-plugin绑定到package阶段并指定classifier为exec这样一次mvn package就能生成两个不同用途的Jar文件。3.3 资源过滤与多环境配置项目通常需要根据环境开发、测试、生产加载不同的配置文件如数据库连接。Maven通过资源过滤Resource Filtering和Profile来实现。1. 资源过滤 在pom.xml中定义属性然后在资源文件如.properties,.yml中使用${property}占位符。构建时Maven会用真实值替换这些占位符。properties db.urljdbc:mysql://localhost:3306/dev_db/db.url /properties build resources resource directorysrc/main/resources/directory filteringtrue/filtering !-- 开启过滤 -- /resource /resources /build在application.properties中spring.datasource.url${db.url}2. 使用Profile实现多环境 Profile允许你定义多套构建配置并通过参数激活。profiles profile iddev/id properties profile.activedev/profile.active db.urljdbc:mysql://localhost:3306/dev_db/db.url /properties activation activeByDefaulttrue/activeByDefault !-- 默认激活 -- /activation /profile profile idprod/id properties profile.activeprod/profile.active db.urljdbc:mysql://prod-server:3306/prod_db/db.url /properties /profile /profiles然后在资源目录下创建application-${profile.active}.properties文件。构建时使用mvn clean package -P prod来激活生产环境配置。注意资源过滤虽然方便但会将配置文件“硬化”到最终的包中无法在不重新打包的情况下切换环境。对于需要高度灵活性的场景如容器化部署更推荐将配置外置如使用Spring Cloud Config构建时打包一个不包含环境特定信息的“干净”包。4. 主流打包方式详解与实战选型4.1 可执行Jar包Fat Jar/Uber Jar的打造这是微服务和独立应用最常见的打包方式。其核心思想是将项目所有依赖的Jar包包括传递依赖以及项目自身的类文件全部解压后重新打包到一个单一的、可执行的Jar文件中。实现方式使用Spring Boot Maven Plugin推荐这是最主流、最省心的方式。plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId executions execution goals goalrepackage/goal !-- 关键目标重新打包 -- /goals /execution /executions configuration mainClasscom.example.Application/mainClass !-- 排除某些不需要的依赖减小体积 -- excludes exclude groupIdorg.projectlombok/groupId artifactIdlombok/artifactId /exclude /excludes /configuration /plugin执行mvn clean package后在target目录下会生成两个文件your-app-1.0.0.jar原始的、不可执行的薄Jar和your-app-1.0.0.jar.original。Spring Boot插件会将薄Jar重命名为.original然后创建一个新的、可执行的胖Jar。使用Maven Shade Plugin更通用适用于非Spring Boot项目。plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-shade-plugin/artifactId version3.5.0/version executions execution phasepackage/phase goals goalshade/goal /goals configuration transformers transformer implementationorg.apache.maven.plugins.shade.resource.ManifestResourceTransformer mainClasscom.example.Application/mainClass /transformer !-- 处理资源文件冲突如多个Jar都有META-INF/LICENSE.txt -- transformer implementationorg.apache.maven.plugins.shade.resource.AppendingTransformer resourceMETA-INF/spring.handlers/resource /transformer /transformers /configuration /execution /executions /plugin胖Jar的优缺点优点部署简单一个文件包含所有启动命令统一java -jar app.jar便于容器化Docker镜像层更清晰。缺点文件体积大任何依赖更新都需要重新打整个包类路径冲突处理更复杂Shade插件可以重命名类来解决。4.2 War包与容器化部署传统Java Web应用通常打包成WARWeb Application Archive文件部署到Tomcat、Jetty等Servlet容器中。标准War包配置将packaging改为war。确保Servlet API等容器的依赖作用域为provided。可选配置maven-war-plugin。plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId version3.4.0/version configuration !-- 指定Web资源目录默认为src/main/webapp -- warSourceDirectorysrc/main/webapp/warSourceDirectory !-- 打包时排除某些文件 -- packagingExcludesWEB-INF/lib/*test*.jar/packagingExcludes !-- 设置War包的文件名 -- warNamemyapp/warName /configuration /pluginWar包 vs 可执行Jar内嵌容器War包部署灵活可以部署到任何兼容的Servlet容器容器可以统一管理监控、日志、集群应用本身更轻量。可执行Jar内嵌Tomcat简化运维无需单独安装配置容器更适合云原生和微服务架构应用完全自包含。现代实践即使是需要部署到外部容器的应用也越来越多地采用“可执行War”模式。即使用Spring Boot打包成War既可以java -jar独立运行内嵌容器也可以部署到外部Tomcat。只需将打包方式改为war并排除内嵌容器的依赖或将其作用域设为provided同时让主类继承SpringBootServletInitializer。4.3 Docker镜像构建与Maven的集成在现代DevOps流程中最终交付物往往是Docker镜像。Maven可以与Docker构建工具无缝集成。1. 使用Spotify的dockerfile-maven-plugin已归档但稳定 这种方式要求你在项目根目录有一个Dockerfile。# Dockerfile FROM openjdk:
Maven POM与打包实战：从依赖管理到Docker镜像构建全解析
1. 项目概述为什么我们需要深入理解POM与打包如果你用Maven开发Java项目超过三个月还在对着pom.xml文件里那些标签感到困惑或者每次打包部署时都祈祷不要出错那这篇文章就是为你准备的。我见过太多项目pom.xml写得像天书依赖冲突、打包失败、部署后类找不到等问题层出不穷最后花在排查上的时间比写业务代码还多。pom.xml远不止是一个依赖声明文件它是Maven项目的“大脑”和“蓝图”定义了项目的身份、结构、行为以及最终产物的形态。而打包Packaging则是将这个蓝图变为可交付成果的最终工序两者结合共同决定了你的项目能否健康构建、顺利部署和稳定运行。简单来说pom.xml负责“想清楚”打包负责“做出来”。但“想清楚”本身就有很多门道依赖版本怎么管理才不冲突多模块项目结构怎么设计不同环境开发、测试、生产的配置如何隔离同样“做出来”也有多种选择打一个可执行的胖JarFat Jar还是打一个包含依赖的War包部署到容器亦或是构建一个包含所有模块的聚合包这些决策都深深烙印在pom.xml的配置和打包生命周期的执行过程中。本文将从一个资深开发者的视角彻底拆解pom.xml的核心元素与打包机制的每一个细节。我不会只罗列标签含义而是结合大量实战中踩过的坑和总结的最佳实践告诉你每个配置项背后的设计意图、常见误区以及如何根据你的项目实际情况做出最优选择。无论你是刚接触Maven的新手还是希望优化现有项目构建流程的老手都能从这里获得可以直接“抄作业”的配置方案和避坑指南。2. POM文件核心架构与设计哲学2.1 POM的本质项目对象模型POMProject Object Model是Maven工作的核心。你可以把它理解为一个项目的“身份证”加“说明书”。它采用XML格式不仅仅是为了人类可读更重要的是机器可解析。Maven通过读取POM文件能精确地知道这个项目是谁坐标、它由什么构成依赖、它要做什么构建生命周期、以及它最终要变成什么样子打包。一个最基本的pom.xml必须包含Maven的模型版本、项目坐标GAV和打包类型。坐标是Maven世界的唯一标识由groupId组织或公司域名的反写如com.example、artifactId项目名如my-app和version版本号如1.0.0-SNAPSHOT组成。packaging默认为jar也可以是war,pom,maven-plugin等。但一个健壮的项目POM远不止这些。它通常包含以下几个关键部分父POM继承通过parent指定一个父项目继承其通用配置如依赖管理、插件配置、仓库地址这是实现多模块项目统一管理和企业级规范的基础。依赖声明在dependencies内声明项目所需的所有库。这里的关键是理解scope作用域和optional可选依赖的用法。依赖管理在dependencyManagement中统一定义依赖及其版本子模块引用时无需指定版本实现了版本的集中管控。构建配置在build中配置资源过滤、插件及其执行目标。这是控制打包行为最核心的区域。属性定义在properties中定义变量如Java版本、依赖版本号实现一处修改处处生效。环境与配置使用profiles为不同环境如dev, test, prod定义不同的配置和构建行为。注意不要在一个简单的单模块项目中过度设计滥用dependencyManagement和profiles会增加复杂度。但当项目规模增长或变为多模块时这些设计会显得至关重要。2.2 依赖管理从混乱到秩序的艺术依赖管理是POM中最容易出问题的地方。很多项目初期依赖随意添加后期冲突不断。一个清晰的依赖管理策略应遵循以下原则1. 作用域Scope的精准使用compile默认值。对编译、测试、运行都有效会打包。provided编译和测试时需要但运行时由容器或JDK提供如Servlet API。不会打包。runtime编译时不需要但测试和运行时需要如JDBC驱动。会打包。test仅用于测试编译和运行阶段。不会打包。system与provided类似但需通过systemPath显式指定本地路径。尽量避免使用因为它破坏了Maven的可移植性。2. 依赖传递与冲突解决 Maven会自动解析传递性依赖。当不同路径引入同一个依赖的不同版本时Maven遵循“最近定义优先”和“第一声明优先”原则。但这常常导致不可预知的行为。最佳实践是使用dependencyManagement在顶层POM中锁定所有常用依赖的版本子模块引用时无需写版本号从根本上杜绝冲突。3. 排除不需要的传递依赖 有时某个依赖会传递引入你不需要或有冲突的库。可以使用exclusions标签将其排除。dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId exclusions exclusion groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-tomcat/artifactId /exclusion /exclusions /dependency4. 使用BOM统一版本 对于Spring Boot、Apache Camel这类大型框架它们会提供BOMBill Of Materials项目。在dependencyManagement中引入BOM可以一键统一所有相关组件的版本确保兼容性。dependencyManagement dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-dependencies/artifactId version2.7.18/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement实操心得我习惯在项目根目录建立一个独立的bom模块专门管理所有第三方依赖的版本。所有业务模块都继承自这个BOM模块。当需要升级某个库比如Log4j2时我只需要修改BOM模块中的一个版本号所有子模块在下次构建时就会自动更新极大降低了升级成本和风险。2.3 多模块项目POM设计实战当业务复杂后单模块项目会变得臃肿。合理的多模块拆分能提高构建速度、明确职责边界、便于团队协作。一个典型的多模块项目结构如下parent-pom (packaging: pom) ├── bom (packaging: pom) - 依赖版本管理 ├── common (packaging: jar) - 通用工具、常量、异常 ├── domain (packaging: jar) - 领域模型、接口 ├── service (packaging: jar) - 业务逻辑实现 ├── web-api (packaging: jar) - 控制器、DTO └── application (packaging: jar) - 启动模块依赖上述模块并打包父POMparent-pom的职责定义modules列出所有子模块。定义公共属性如Java版本、源码编码、项目版本。配置所有子模块共用的插件如编译器插件、源码打包插件。不定义dependencies只定义dependencyManagement。子模块POM的写法通过parent指向父POM。只需声明本模块特有的依赖版本从父POM的dependencyManagement中继承。可以覆盖父POM中定义的属性谨慎使用。一个常见的坑子模块之间循环依赖。例如service模块依赖web-api而web-api又反过来依赖service。这会导致Maven无法确定构建顺序。解决方法是重新审视模块划分将公共部分提取到common或domain模块中确保依赖关系是单向的、有层次的。3. Maven生命周期与打包核心原理3.1 深入理解三套生命周期Maven的生命周期Lifecycle是理解打包如何发生的关键。它包含三套相互独立的生命周期每套生命周期由一系列阶段Phase组成clean清理生命周期包含pre-clean,clean,post-clean阶段。mvn clean会删除target目录。default核心构建生命周期包含编译、测试、打包、安装、部署等关键阶段。这是我们最常打交道的。site站点文档生命周期用于生成项目报告和站点文档。重点在于default生命周期其核心阶段顺序如下validate验证项目是否正确POM是否有效。compile编译项目主源代码。test-compile编译测试源代码。test使用合适的单元测试框架运行测试。package将编译后的代码打包成可分发格式如JAR、WAR。这是打包的核心动作发生阶段。verify对集成测试结果进行检查确保质量达标。install将包安装到本地Maven仓库供本地其他项目依赖。deploy将最终的包复制到远程仓库供其他开发者和项目使用。关键理解当你执行mvn package时Maven会按顺序执行从validate到package的所有阶段。每个阶段背后都绑定了一个或多个插件目标Plugin Goal来具体执行任务。例如package阶段绑定了maven-jar-plugin:jar目标对于打包类型为jar的项目。3.2 插件生命周期背后的执行引擎生命周期阶段是“做什么”插件Plugin是“怎么做”。Maven本身几乎不做任何具体工作所有工作都委托给插件完成。插件配置示例控制如何打Jar包。build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId version3.3.0/version configuration !-- 指定生成的Jar包中包含MANIFEST.MF文件的主类 -- archive manifest mainClasscom.example.Application/mainClass !-- 添加类路径使Jar包能引用依赖的Jar -- addClasspathtrue/addClasspath classpathPrefixlib//classpathPrefix /manifest /archive !-- 排除某些文件不打进Jar包 -- excludes exclude**/*.properties/exclude /excludes /configuration !-- 可以将插件目标绑定到生命周期的特定阶段 -- executions execution phasepackage/phase goals goaljar/goal /goals /execution /executions /plugin /plugins /build插件管理和依赖管理类似可以在父POM中使用pluginManagement统一管理插件的版本和基础配置子模块只需引用插件而无需重复配置版本。实操心得对于Spring Boot项目我们通常使用spring-boot-maven-plugin来打包它会生成一个可执行的、包含所有依赖的“胖Jar”。但有时你可能需要同时生成一个普通的Jar给其他项目依赖和一个可执行的胖Jar。这时可以配置该插件绑定到package阶段同时配置maven-jar-plugin绑定到package阶段并指定classifier为exec这样一次mvn package就能生成两个不同用途的Jar文件。3.3 资源过滤与多环境配置项目通常需要根据环境开发、测试、生产加载不同的配置文件如数据库连接。Maven通过资源过滤Resource Filtering和Profile来实现。1. 资源过滤 在pom.xml中定义属性然后在资源文件如.properties,.yml中使用${property}占位符。构建时Maven会用真实值替换这些占位符。properties db.urljdbc:mysql://localhost:3306/dev_db/db.url /properties build resources resource directorysrc/main/resources/directory filteringtrue/filtering !-- 开启过滤 -- /resource /resources /build在application.properties中spring.datasource.url${db.url}2. 使用Profile实现多环境 Profile允许你定义多套构建配置并通过参数激活。profiles profile iddev/id properties profile.activedev/profile.active db.urljdbc:mysql://localhost:3306/dev_db/db.url /properties activation activeByDefaulttrue/activeByDefault !-- 默认激活 -- /activation /profile profile idprod/id properties profile.activeprod/profile.active db.urljdbc:mysql://prod-server:3306/prod_db/db.url /properties /profile /profiles然后在资源目录下创建application-${profile.active}.properties文件。构建时使用mvn clean package -P prod来激活生产环境配置。注意资源过滤虽然方便但会将配置文件“硬化”到最终的包中无法在不重新打包的情况下切换环境。对于需要高度灵活性的场景如容器化部署更推荐将配置外置如使用Spring Cloud Config构建时打包一个不包含环境特定信息的“干净”包。4. 主流打包方式详解与实战选型4.1 可执行Jar包Fat Jar/Uber Jar的打造这是微服务和独立应用最常见的打包方式。其核心思想是将项目所有依赖的Jar包包括传递依赖以及项目自身的类文件全部解压后重新打包到一个单一的、可执行的Jar文件中。实现方式使用Spring Boot Maven Plugin推荐这是最主流、最省心的方式。plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId executions execution goals goalrepackage/goal !-- 关键目标重新打包 -- /goals /execution /executions configuration mainClasscom.example.Application/mainClass !-- 排除某些不需要的依赖减小体积 -- excludes exclude groupIdorg.projectlombok/groupId artifactIdlombok/artifactId /exclude /excludes /configuration /plugin执行mvn clean package后在target目录下会生成两个文件your-app-1.0.0.jar原始的、不可执行的薄Jar和your-app-1.0.0.jar.original。Spring Boot插件会将薄Jar重命名为.original然后创建一个新的、可执行的胖Jar。使用Maven Shade Plugin更通用适用于非Spring Boot项目。plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-shade-plugin/artifactId version3.5.0/version executions execution phasepackage/phase goals goalshade/goal /goals configuration transformers transformer implementationorg.apache.maven.plugins.shade.resource.ManifestResourceTransformer mainClasscom.example.Application/mainClass /transformer !-- 处理资源文件冲突如多个Jar都有META-INF/LICENSE.txt -- transformer implementationorg.apache.maven.plugins.shade.resource.AppendingTransformer resourceMETA-INF/spring.handlers/resource /transformer /transformers /configuration /execution /executions /plugin胖Jar的优缺点优点部署简单一个文件包含所有启动命令统一java -jar app.jar便于容器化Docker镜像层更清晰。缺点文件体积大任何依赖更新都需要重新打整个包类路径冲突处理更复杂Shade插件可以重命名类来解决。4.2 War包与容器化部署传统Java Web应用通常打包成WARWeb Application Archive文件部署到Tomcat、Jetty等Servlet容器中。标准War包配置将packaging改为war。确保Servlet API等容器的依赖作用域为provided。可选配置maven-war-plugin。plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId version3.4.0/version configuration !-- 指定Web资源目录默认为src/main/webapp -- warSourceDirectorysrc/main/webapp/warSourceDirectory !-- 打包时排除某些文件 -- packagingExcludesWEB-INF/lib/*test*.jar/packagingExcludes !-- 设置War包的文件名 -- warNamemyapp/warName /configuration /pluginWar包 vs 可执行Jar内嵌容器War包部署灵活可以部署到任何兼容的Servlet容器容器可以统一管理监控、日志、集群应用本身更轻量。可执行Jar内嵌Tomcat简化运维无需单独安装配置容器更适合云原生和微服务架构应用完全自包含。现代实践即使是需要部署到外部容器的应用也越来越多地采用“可执行War”模式。即使用Spring Boot打包成War既可以java -jar独立运行内嵌容器也可以部署到外部Tomcat。只需将打包方式改为war并排除内嵌容器的依赖或将其作用域设为provided同时让主类继承SpringBootServletInitializer。4.3 Docker镜像构建与Maven的集成在现代DevOps流程中最终交付物往往是Docker镜像。Maven可以与Docker构建工具无缝集成。1. 使用Spotify的dockerfile-maven-plugin已归档但稳定 这种方式要求你在项目根目录有一个Dockerfile。# Dockerfile FROM openjdk: