最近一直在研究前公司的架构,发现原公司的架构还是很不错的,对于生产环境以及测试环境这一点,虽然没有配置中心,但也是一定程度实现了正式环境以及测试环境的分离。
闲话不多说,现在直接上代码:
首先需要在pom文件中确定filter和要filter的资源,这是通过在build节点中添加filter和resource来实现的,示例如下:
<build>
<filters>
<filter>${env}.properties</filter>
</filters>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>
上述配置表示要对<filter>采用的过滤文件${env}.properties</filter>下的资源进行过滤,如果不写,默认当前目录,因为该目录下没有二进制文件,所以没有excluding。<filtering></filtering>true表示需要过滤,<directory></directory>表示需要过滤的文件,过滤时采用的过滤文件为${env}.properties文件,其中${env}是一个变量,表示当前使用的环境,这是通过在pom文件中通过profile定义的,如下所示:
<profiles>
<profile>
<id>dev</id>
<properties>
<!-- 测试环境 -->
<env>dev</env>
</properties>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
</profile>
<profile>
<id>formal</id>
<properties>
<!-- 正式环境 -->
<env>formal</env>
</properties>
</profile>
</profiles>
这里需要解释一下activation的意思:
<!--自动触发profile的条件逻辑。Activation是profile的开启钥匙。profile的力量来自于它能够在某些特定的环境中自动使用某些特定的值;这些环境通过activation元素指定。activation元素并不是激活profile的唯一方式。-->
通俗一点说,如果检测到匹配的属性,则激活该该配置项。
这样在开发时就不用每次指定这个值。在测试和部署上线时分别通过-P传入当前的profile id,这样maven就会将env变量设置为对应的值,从而导致使用不同的filter文件来对resources下的文件进行过滤替换。
具体如下图
版权声明:本文为博主原创文章,未经博主允许不得转载。