MAVEN大白话笔记（二）：pom文件配置profile及resourcesa解决spring不同环境配置文件问题

pom文件配置profile及resourcesa解决spring不同环境配置文件问题

（一）摘要

我们使用spring的时候都会有配置文件，比如application.properties、log4j.properties和mybatis-config.xml等等。而我们一般都会有不同的环境需要部署：开发环境、测试环境和生产环境，而不同的环境则会有不同的配置，比如数据库ip。解决这个问题，我所熟悉的有两种策略：一种是spring的profile参数配置，一种是pom文件的profile配置。还有一个叫gradle好像也可以，我没有用过就不多说了。

（二）spring的profiles策略

spring的配置使用例子：
第一步：创建一个application-dev.properties及application.properties文件。

第二步：application.properties文件配置，这里端口定为8686：

server.port=8686
spring.profiles.active=dev

第三步：application-dev.properties文件配置，这里端口定为8181：

server.port=8181

第四步：运行，端口为8181，使用的是application-dev.properties，测试成功：

spring的这种方式是spring容器扫描文件的时候去根据profiles的值来进行判断的，所以需要消耗一定的性能，说是这么说，但只是启动的时候进行那么一下判断而已。

（三）maven的profiles策略

maven的pom文件里面也有一个配置profiles的功能，这个profiles配合resources可以实现打包时根据配置的生效profiles的路径进行打包。
第一步：
创建配置文件，config目录下有三个文件夹：dev（开发）、pro（生产）、test（测试）。

第二步：
配置pom文件

<!-- activation指定生效的profile -->
    <profiles>    <!-- profile组 -->
        <profile>    <!-- 一个profile -->
            <id>develop</id>   <!-- id，不能重复 -->
            <properties>    <!-- 该profile映射的路径 -->
                <profiles.active>dev</profiles.active>
            </properties>
            <activation>    <!-- 指定生效的profile -->
                <activeByDefault>true</activeByDefault>
            </activation>
        </profile>
        <profile>
            <id>test</id>    
            <properties>
                <profiles.active>test</profiles.active>
            </properties>
        </profile>
        <profile>
            <id>project</id>
            <properties>
                <profiles.active>pro</profiles.active>
            </properties>
        </profile>
    </profiles>

    <build>
        <!-- 配置文件打包时的映射路径，profiles.active获取当前生效的profile路径 -->
        <resources>    <!-- resources组 -->
            <resource>    <!-- 一个resource -->
                <directory>src/main/resources</directory>    <!-- 需要处理的路径 -->
                <excludes>    <!-- 需要处理的文件夹 -->
                    <exclude>config/</exclude>
                </excludes>
            </resource>
            <resource>
                <directory>src/main/resources/config/${profiles.active}</directory>    <!-- 打包文件所在的路径，profiles.active就是profiles里面生效的路径 -->
                <targetPath>.</targetPath>    <!-- 可有可无 -->
            </resource>
        </resources>
    </build>

图片说明：

第三步：
执行打包命令：mvn clean package -Dmaven.test.skip=true

这里生效的是dev，最终打包后target里面的也是dev文件夹里面的文件，至此pom的profiles的配置完成。

（四）maven的profiles的优先级

当resources里面配置的文件和profile对应文件夹中文件同名的时候，谁生效呢？




打包后target中同名的为resources的文件，而不同名的就会打进去，这个问题需要注意！

（五）spring和maven的区别

spring的profiles的使用简单便捷，而maven的略显麻烦。但是spring的只能识别application对应的配置文件，且spring是在容器初始化的时候进行识别的，而maven是文件夹级别的，文件夹里面可以放置任意的配置文件。而且maven是在打包的时候进行识别的，但是这个也引生了一个问题：难道我一个开发的每一次都要打包后再运行然后调试？太麻烦了！！！其实这个没什么，直接将dev文件夹中的配置文件复制到resources中即可，发布的时候删除掉就好。

（六）应用场景思考

说了那么久，那么究竟这个东东有什么用呢？首先先问一个问题：公司的管理情况！
（1）如果公司管理很规范，开发、测试和发布都有一套流程需要走，那么可以这么处理：开发人员不需要使用profile策略，直接在resources中设置配置文件，用一套配置文件即可。而挑选一位管理者，管理不同环境的配置文件打包问题，这里就可以使用profile策略了。
（2）如果公司管理并不规范，速度为王，没有特定的管理配置文件的人员，所有开发者均可以发布。则每个人都可以使用profile策略了。
这个profile策略也是一个权限管理，比如普通的开发人员没有必要知道生产环境中的配置信息，因为普通的开发人员离职比较普遍，所以这个profile就可以将生产环境的配置信息管理起来。可能你会说我手动改不也一样吗？是啊，但是干嘛要手动改呢？做人懒一点不好吗~~~，而且手动改的话，错误率大大提高，来自我的黑历史(TωT)