2023年12月13日发(作者：)
利用assembly插件分环境打包配置文件
首先, 郑重的吐槽下度娘, 能找到的资料, 都是说针对打包
的, 找了好一会儿, 才找到针对
war
包.
开始并不顺利, 因为在父子模块的场景下, 有war,有jar. 最后发现打包的lib里包含war包. 这样不是重复打包吗, 而且, 并不
能打成标准war包结构.
好啦, 现在上正解.
工程结构:
parent //pom
| common //jar
| dao //jar
| web //war
针对中这种结构的工程, 网上的
的做法并不适用. 主要是: 1)会将
web
模块的war包打进lib文件中; 2)目录结构不是war包应有的结构. 前者是
因为maven自带的编译打包工具会先执行打包操作, 这样轮到assembly打包时会将打好的war包打进lib文件夹中.
针对上文的工程结构, 需要:
1.
parent
pom中统一配置自带的编译插件. 主要是指定编译的jdk版本.(否则默认会使用1.5的. 不会的需要补充学习下).
2.
jar
模块如果需要分环境打包配置文件, 则不需要任何多余的配置, 使用的默认的jar打包即可.
3.
web
模块是重点. 下文的配置都是针对web的配置. 通常web工程更多的需要分环境打包配置文件.
web配置文件结构
我这里的思路是:
resources
下可以放置每个环境都需要的
公共
配置文件. 分环境的放在
./src/main/assembly/
下.
1 web模块的中的
profiles
配置
2 web模块的中引入
assembly
插件
3 配置定制
xsi:schemaLocation="/plugins/maven-assembly-plugin/assembly/1.1.0 /xsd/">
这里采用的方案是, 不同环境公用同一个
l文件.
4 执行打包的命令
各环境对应的命令:
mvn clean package
mvn clean package -P dev
mvn clean package -P test
mvn clean package -P prod
后记
分环境打包的分支控制策略有两种:
1. 通过
profile
配置不同的环境下的配置, 然后打包的时候通过参数
-P 环境id
定位到对应
profile
, 就会执行该
profile
下的所有配置, 包括自定义
的
properties
(这里的
properties
和
profile
外层的效果一样).
本文采用的就是这个思路
.
这种方案的好处是, 可以方便的定义默认打包环境.
2. 不同环境的配置文件分别放在不同的路径下, 打包配置中用
${env}
动态执行路径, 然后打包时带上参数:
-Denv=环境名称
, 即动态手动指定环境名,
定位到对应路径下的配置文件. 这种方案看似简单好实施, 但有个缺陷就是
不方便执行默认打包环境
.
最后, 再次重复一个坑点:
下图中两种property效果完全不同的, 上面的我完全不知道有什么鸟用, 下面的才是关键.
properties
发布评论