maven

最近一直在研究前公司的架构，发现原公司的架构还是很不错的，对于生产环境以及测试环境这一点，虽然没有配置中心，但也是一定程度实现了正式环境以及测试环境的分离。

闲话不多说，现在直接上代码：

首先需要在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下的文件进行过滤替换。

具体如下图