如果在配置中勾选了多套配置,则以pom.xml文件中 profiles中 配置 最后一个配置为准。
maven中配置profile节点:
<project>
....
<profiles>
<profile>
<!-- 生产环境 -->
<id>prod</id>
<properties>
<profiles.active>prod</profiles.active>
</properties>
</profile>
<profile>
<!-- 本地开发环境 -->
<id>dev</id>
<properties>
<profiles.active>dev</profiles.active>
</properties>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
</profile>
<profile>
<!-- 测试环境 -->
<id>test</id>
<properties>
<profiles.active>test</profiles.active>
</properties>
</profile>
</profiles>
</project>
spring boot application.properties文件中引用maven profile节点的值:
spring.profiles.active=@profiles.active@
http://docs.spring.io/spring-boot/docs/1.5.2.RELEASE/reference/htmlsingle/
非spring boot 项目中配置
http://www.itwendao.com/article/detail/85631.html
http://zilongsky-gmail-com.iteye.com/blog/2032001
http://dolszewski.com/spring/spring-boot-properties-per-maven-profile/
1.概述
按照项目开发的流程,项目工程需要经历开发人员本地测试环境(dev),进入测试阶段后有测试环境(test),测试无误后需要将程序发布到生产环境(production)下,而对于这三个不同的项目环境,应用程序要在该环境下运行,必须有不同的配置项,如开发和生产环境使用不同的数据库地址,不同的线程池参数,因此需要对不同的项目环境进行不同的配置,为了简化和规范这些参数配置,需要对其进行统一规范管理。
2.配置项管理
2.1三个环境
按照项目所处阶段,分为
开发环境(dev)
该环境下的配置项只影响开发人员本地代码配置,在项目初期代码本地编写调试时启用,如可以设置更低的Log级别帮助开发人员查看更为详细的log信息。
测试环境(test)
该环境配置影响整个团队的测试环境。
正式生产环境(production)
程序最终发布后所需要的参数配置,该环境下的配置项修改将直接影响最终用户的使用和应用程序的运行。
系统的配置项统一放在src/main/filters/目录下,三个环境的配置文件分别为
filter-dev.properties
filter-test.properties
filter-production.properties
这三个文件的用法见2.3.2节介绍
2.2识别配置项
开发人员在做日常需求时,需要对程序的配置项进行识别,严格禁止将变量写死代码的情况出现。下列情况下需要考虑将变量作为系统的配置项
1) 一些系统级参数、
数据库连接参数,日志级别
2) 外部依赖webservice链接地址
对于不同的环境下所依赖的外部webservice也应该根据所处环境不同依赖不同的地址,如开发环境下依赖外部系统开发环境的地址。
3) 一些业务数据
系统可能要使用一些业务数据,如对某一个岗位信息特殊处理,该岗位信息在生产开发环境数据库中的id不一致,这种情况下也需要将其作为配置项处理。
2.3Maven配置
项目工程统一使用maven的profile插件定义不同的项目构建环境(dev, test, production),通过filter插件为不同环境下的配置项注入对应的参数值来实现动态配置目标。
2.3.1定义profile
在POM.xml中配置3个profile,对应项目所处的3个不同的环境-dev, test, production, profile的id属性即为每个环境赋予一个唯一的标示,<properties>元素的内容则是以key-value的形式出现的键值对,如我们定义了一个变量<env>,其值在不同的环境下(不同id)被赋予了不同的值(dev, production, test),要激活不同的环境打包,我们可以在命令行通过mvn package –P${profileId}来让其运行,为了开发便利,默认激活的是dev开发环境,即开发人员不需要通过命令行手动输入-p参数也能运行dev环境的打包。
<!-- 不同的打包环境 -->
<profiles>
<!-- 开发环境,默认激活 -->
<profile>
<id>dev</id>
<properties>
<env>dev</env>
</properties>
<activation>
<activeByDefault>true</activeByDefault><!--默认启用的是dev环境配置-->
</activation>
</profile>
<!-- 生产环境 -->
<profile>
<id>production</id>
<properties>
<env>production</env>
</properties>
</profile>
<!-- 测试环境 -->
<profile>
<id>test</id>
<properties>
<env>test</env>
</properties>
</profile>
</profiles>
2.3.2定义filter(由filter插件完成此操作)
可以使用Maven来对项目资源进行变量替换。在资源过滤被激活的时候,Maven会扫描资源,寻找由${}包围的Maven属性的引用。
一旦它找到这些引用,它就会使用合适的值去替换它们,当需要根据目标部署平台使用不同的配置来参数化一个构建的时候,这就非常有用。
通常一个在src/main/resources目录下的.properties文件或者XML文档会包含对外部资源的引用,如需要根据目标部署平台进行不同配置的数据库或网络地址。
例如,一个从数据库读取数据的系统有一个XML文档,其包含了数据库的JDBC URL以及安全凭证。如果你在开发和产品环境使用不同的数据库,使用Maven Profile来为不同的部署环境定义不同的配置。
Filter的配置(在<build>元素下添加节点)如下:
首先引入配置文件的地址,2.1节已经介绍过统一放在src/main/filters目录下,注意这个filter的配置有个filter-${env}.properties,这个${env}变量就是在父pom.xml中定义的profile的id,
当通过命令行mvn package –P${profileId}时,按${env}变量就会用实际传入的值替换,从而达到针对不同环境采用不同配置文件的目的。
<filters>
<filter>src/main/filters/filter-${env}.properties</filter>
</filters>
配置需要被替换的资源文件地址
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
如在src/main/resources/目录下的env.properties文件的内容如下
### database connection configuration
jdbc.driverClassName=${jdbc.driverClassName}
jdbc.url=${jdbc.url}
jdbc.username=${jdbc.username}
jdbc.password=${jdbc.password}
当执行完毕打包操作后,位于war包中的env.properties文件中所有被的${}都会被filters下文件中的值所替换。
http://blog.sina.com.cn/s/blog_6c969b4a0102wfks.html
由于项目的需要, 今天给spirng boot项目添加了profile功能。再网上搜索了一圈,也没有找到满意的参考资料,其实配置并不难,就是没有一个one stop(一站式)讲解的地方,所以有了写这篇博客的想法。由于本人水平有限,文中任何错误和纰漏欢迎大家反馈。希望本文可以给你带来帮助。
本文实现的目标:
1 使用了maven的profile功能
2 使用了Spring Boot的profile功能
3 集成了1和2的功能
4 在eclipse中运行mvn工程,使用开发环境的profile。
5 通过mvn在命令行中打包时,可以指定相应的profile。
什么是profile,解决什么问题呢?举个例子。一般在开发项目的时候要有多个环境,如开发环境、测试环境、生产环境,他们的配置文件一般不同。当我们要向各个环境发布程序时,需要人工处理这些配置文件,这显然麻烦且易错。有了profile,一切问题就简单了。只要在maven打包时使用下面命令即可。
[plain] view plain copy
- mvn clean package -Dmaven.test.skip=true -P prod
解释一下, -P prod 就是告诉maven要使用名字为prod的profile来打包,即所有的配置文件都使用生产环境(prod是自己定义的,在这里自定义为生产环境)。
实现思路简述:
maven支持profile功能,当使用maven profile打包时,可以打包指定目录和指定文件,且可以修改文件中的变量。spring boot也支持profile功能,只要在application.properties文件中指定spring.profiles.active=xxx 即可,其中xxx是一个变量,当maven打包时,修改这个变量即可。
具体实现:
A段,介绍coolpro工程的配置。
这个工程只需要修改pom.xml文件即可,需要定义具体maven的profile。定义完毕之后,当我们使用mvn clean package -P dev 时,maven就知道了profileActive=dev这个属性生效了。其中profileActive可以自己定义,就是一个maven的自定义属性。
pom.xml文件如下:
B段,介绍coolpro-api工程的配置
这个工程是一个web工程,主要是想根据指定的profile配置相应的spring boot运行环境。如:如果profile是dev,配置web服务器的监听端口为8010;profile为test,则端口为8020;profile为prod,则端口为8030。
工程中有4个文件:
application.properties, 包含通用配置的文件。文件中有spring.profiles.active=@profileActive@的属性。spring boot的profile是通过spring.profiles.active属性来配置的,这里的profileActive和上面coolpro工程中配置的profileActive属性名要一致。这样,在运行mvn命令时,maven就会帮我们将@profileActive@替换成指定的profile。
application-dev.properties, 当mvn -P dev时, 需要打包这个文件。
application-test.properties, 当mvn -P test时, 需要打包这个文件。
application-prod.properties, 当mvn -P prod时, 需要打包这个文件。
pom.xml配置:
application.properties文件:
其他3个文件见截图:
C段,介绍coolpro-core工程的配置
配置完成了。看效果。
1 在Eclipse环境中,直接运行项目。
2 使用maven命令,打包这个应用。
1)以开发环境打包:mvn clean package -Dmaven.test.skip=true -P dev -e
结果如下:
查看api工程:
查看core工程:
以此类推, 可以运行
mvn clean package -Dmaven.test.skip=true -P test -e
mvn clean package -Dmaven.test.skip=true -P prod -e
注意两点:
1 在属性文件中替换变量时,使用@符合。
最开始,使用$符号,就是不能替换,在网上搜索一下,原来是maven的maven-resources-plugin可以定义这个替换的符号。通过eclipse提供的Maven Pom editor编辑器打开pom.xml文件,在“Effective POM”选项卡中,可以看到定义的是@这个符号。
2 怎么在启动spring boot应用时,打印正在使用的profile,避免配置错误呢?可以参考如下代码。
[java] view plain copy
1. public static void main(String[] args) {
2. class, args);
3. String[] activeProfiles = ctx.getEnvironment().getActiveProfiles();
4. for (String profile : activeProfiles) {
5. "Spring Boot 使用profile为:{}" , profile);
6. }
7. }