maven多环境多配置文件的解决方案
来源:互联网 发布:权力的48条法则 知乎 编辑:程序博客网 时间:2024/04/29 10:50
方案1:需求是:
1.在本地开发的时候,war包部署在本地的时候contextroot是dev-geoflow
2.在持续集成的时候,war包部署在服务器上的的时候,contextroot是geoflow
3.默认情况下,使用2
首先配置一个用于本地开发的profile
<profiles> <profile> <id>dev</id> <properties> <webXmlPath>webxml/develop</webXmlPath> </properties> </profile> </profiles>
然后配置一个默认的环境变量
<properties> <webXmlPath>webxml/release</webXmlPath> </properties>
在项目目录下创建webxml目录,分别有两个子目录develop和release
目录下分别配置了sun-web.xml,contextroot值不一样。
现在在maven-war-plugin上使用变量${webXmlPath}
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-war-plugin</artifactId> <version>2.1.1</version> <configuration> <webResources> <resource> <directory>${webXmlPath}</directory> <targetPath>WEB-INF</targetPath> </resource> </webResources> </configuration> </plugin>好了。当运行mvn package的时候,将webxml/release目录下的xml文件打包到WEB-INF内。这是默认情况。持续集成服务器使用。
当运行mvn package -P dev 的时候,将webxml/develop目录下的xml文件打包的WEB-INF内,这是本地开发使用。
方案2:
构建项目时可能会遇到在测试(如单元测试)、开发、模拟、生产等不同环境下需要不同配置(properties、xml)或资源(jpg、png、mp3)的情况。比如常见的数据库连接(即 jdbc url)的值,在不同的环境下可能有如下几种值:
测试环境:jdbc:mysql://localhost:3306/foobar_test
开发环境:jdbc:mysql://localhost:3306/foobar_dev
模拟环境:jdbc:mysql://192.168.1.11:3306/foobar
生产环境:jdbc:mysql://192.168.1.10:3306/foobar
或者同样是生产环境,针对(产品)交付给A公司客户的与交付给B公司客户的需要不同配置或者资源,比如产品界面中的公司名称、公司LOGO等。
又或者针对不同的操作系统(如 Windows,Linux)需要为某个配置设定不同的文件路径。
可见,在不同的软件开发生命周期阶段、不同的最终客户(用户)环境、不同的运行平台都有可能需要不同配置或资源的情况。假如各个环境下的差别很小的话,我们可以在项目编译之后手工修改或者写个 shell script 自动修改,但如果需要修改的项目很多而且复杂的话,则应该使用 Apache Maven 的 Profile 和 Filtering 功能来解决。(当然前提是你的项目必须是用 Maven 构建的啦,哈哈,还有测试阶段所使用到的资源文件实际上 Maven 默认已经划分出来,所以并不需要本文所说的方法)
Filtering 功能
Filtering 是 Maven Resources Plugin 的一个功能,它会使用系统属性或者项目属性的值替换资源文件(*.properties,*.xml)当中 ${…} 符号的值。比如你系统属性有一项 “user.name=foobar”,那么资源文件当中的 ${user.name} 符号会在 Maven 编译时自动被替换为 “foobar”。
举个例子:
默认的项目资源文件位于 “src/main/resources” 目录,在该目录下创建一个文件 “test.properties”,里面写上一行:
Hello ${user.name}
然后修改项目文件(pom.xml)启用 filtering 功能,如:
然后编译项目:
$mvn clean compile -Duser.name=foobar
查看输出文件 target/classes/test.properties 的内容,可见原先的 “Hello {user.name}” 已经变成 “Hello foobar”。
我们也可以把 filtering 用到的变量写在项目属性段里,比如:
如果属性项比较多的话,最佳实践是把他们抽离出来独立一个属性文件,比如在你项目目录(即 pom.xml 文件所在的目录)新建一个属性文件 project.properties:
user.name=foobar
user.email=foobar@some.com
然后在 build/filters/filter 里指明使用这个属性文件作为 filtering 属性值的来源:
Profile 功能
Profile 的作用是允许你在项目文件(pom.xml)里定义若干个 profile 段,然后在编译时选择其中的一个用于覆盖项目文件原先的定义。接着上一个例子,如果我们需要为开发环境和生产环境定义不同的 user.name 属性值,则我们在项目目录里创建两个属性文件:
profile-development.properties,内容
user.name=foobar
profile-production.properties,内容
user.name=tom
然后在项目文件(pom.xml)里增加 profile 段,如下:
在编译项目时,可以使用 -P 参数指定需要使用的 profile 的 id,比如下面命令将会使用 development profile:
$mvn clean compile -Pdevelopment
如果想使用 production profile 则执行如下命令:
$mvn clean compile -Pproduction
假如不指定 -P 参数的话,则会使用 activeByDefault=true 的一项(即 development)。
至此,通过 filtering 和 profile 功能实现了为开发环境和生产环境使用不同配置值的目的。当然 profile 还可以允许你添加更多的定义,比如为某一个 profile 添加不同的资源文件。在一些大中型项目里,不同的环境可能仅仅修改配置值并不足够,可能还需要某个配置文件整个替换,那么就应该在 profiles/profile/build/resources 段里指定了。
测试环境:jdbc:mysql://localhost:3306/foobar_test
开发环境:jdbc:mysql://localhost:3306/foobar_dev
模拟环境:jdbc:mysql://192.168.1.11:3306/foobar
生产环境:jdbc:mysql://192.168.1.10:3306/foobar
或者同样是生产环境,针对(产品)交付给A公司客户的与交付给B公司客户的需要不同配置或者资源,比如产品界面中的公司名称、公司LOGO等。
又或者针对不同的操作系统(如 Windows,Linux)需要为某个配置设定不同的文件路径。
可见,在不同的软件开发生命周期阶段、不同的最终客户(用户)环境、不同的运行平台都有可能需要不同配置或资源的情况。假如各个环境下的差别很小的话,我们可以在项目编译之后手工修改或者写个 shell script 自动修改,但如果需要修改的项目很多而且复杂的话,则应该使用 Apache Maven 的 Profile 和 Filtering 功能来解决。(当然前提是你的项目必须是用 Maven 构建的啦,哈哈,还有测试阶段所使用到的资源文件实际上 Maven 默认已经划分出来,所以并不需要本文所说的方法)
Filtering 功能
Filtering 是 Maven Resources Plugin 的一个功能,它会使用系统属性或者项目属性的值替换资源文件(*.properties,*.xml)当中 ${…} 符号的值。比如你系统属性有一项 “user.name=foobar”,那么资源文件当中的 ${user.name} 符号会在 Maven 编译时自动被替换为 “foobar”。
举个例子:
默认的项目资源文件位于 “src/main/resources” 目录,在该目录下创建一个文件 “test.properties”,里面写上一行:
Hello ${user.name}
然后修改项目文件(pom.xml)启用 filtering 功能,如:
<project>...<build> ... <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> </resource> ... </resources> ...</build>...</project>
然后编译项目:
$mvn clean compile -Duser.name=foobar
查看输出文件 target/classes/test.properties 的内容,可见原先的 “Hello {user.name}” 已经变成 “Hello foobar”。
我们也可以把 filtering 用到的变量写在项目属性段里,比如:
<project> ... <properties> <user.name>foobar</user.name> <user.email>foobar@some.com</user.email> </properties> ...</project>
如果属性项比较多的话,最佳实践是把他们抽离出来独立一个属性文件,比如在你项目目录(即 pom.xml 文件所在的目录)新建一个属性文件 project.properties:
user.name=foobar
user.email=foobar@some.com
然后在 build/filters/filter 里指明使用这个属性文件作为 filtering 属性值的来源:
<project> ... <build> ... <filters> <filter>project.properties</filter> </filters> ... </build> ...</project>
Profile 功能
Profile 的作用是允许你在项目文件(pom.xml)里定义若干个 profile 段,然后在编译时选择其中的一个用于覆盖项目文件原先的定义。接着上一个例子,如果我们需要为开发环境和生产环境定义不同的 user.name 属性值,则我们在项目目录里创建两个属性文件:
profile-development.properties,内容
user.name=foobar
profile-production.properties,内容
user.name=tom
然后在项目文件(pom.xml)里增加 profile 段,如下:
<project> ... <profiles> <profile> <id>development</id> <activation> <activeByDefault>true</activeByDefault> </activation> <build> <filters> <filter>profile-development.properties</filter> </filters> </build> </profile> <profile> <id>production</id> <build> <filters> <filter>profile-production.properties</filter> </filters> </build> </profile> </profiles></project>
在编译项目时,可以使用 -P 参数指定需要使用的 profile 的 id,比如下面命令将会使用 development profile:
$mvn clean compile -Pdevelopment
如果想使用 production profile 则执行如下命令:
$mvn clean compile -Pproduction
假如不指定 -P 参数的话,则会使用 activeByDefault=true 的一项(即 development)。
至此,通过 filtering 和 profile 功能实现了为开发环境和生产环境使用不同配置值的目的。当然 profile 还可以允许你添加更多的定义,比如为某一个 profile 添加不同的资源文件。在一些大中型项目里,不同的环境可能仅仅修改配置值并不足够,可能还需要某个配置文件整个替换,那么就应该在 profiles/profile/build/resources 段里指定了。
方案3:
项目根pom.xml中定义:
<pre name="code" class="html"><profiles> <profile> <activation><activeByDefault>true</activeByDefault></activation><id>test</id><build><plugins><plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-antrun-plugin</artifactId><version>1.1</version><executions><execution><phase>compile</phase><goals><goal>run</goal></goals><configuration><tasks><echo>Using env.test.properties</echo><copy file="src/main/resources/env.test.properties"tofile="${project.build.outputDirectory}/env.properties" /></tasks></configuration></execution></executions></plugin></plugins></build></profile><profile><id>prod</id><build><plugins><plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-antrun-plugin</artifactId><version>1.1</version><executions><execution><phase>compile</phase><goals><goal>run</goal></goals><configuration><tasks><echo>Using env.prod.properties</echo><copy file="src/main/resources/env.prod.properties"tofile="${project.build.outputDirectory}/env.properties" /></tasks></configuration></execution></executions></plugin></plugins></build> </profile></profiles>
0 0
- maven多环境多配置文件的解决方案
- 项目配置文件多环境解决方案
- Maven 多环境配置文件管理
- idea maven多环境配置文件
- maven项目web配置文件多环境配置
- maven多环境配置文件设置,打包是配置文件变量替换
- 使用maven profile指定配置文件打包适用多环境
- Maven插件-打包时多环境配置文件设置
- Spring-boot与maven多环境配置文件设置
- 使用maven管理不同环境的配置文件
- Maven根据不同的环境打包配置文件
- maven—profiles区分环境的配置文件
- maven 多配置文件设置
- maven 多module环境下打包出现boot-inf的解决方案
- maven的多环境配置
- maven根据不同的运行环境,打包不同的配置文件
- maven 使用多个配置文件
- 用maven filter 管理不同环境的配置文件
- #2014 CSDN博文大赛#
- swift UIImageView使用
- 练手AIO
- Google入门到精通(搜索方法经典)
- 与文件相关的系统调用
- maven多环境多配置文件的解决方案
- 基于HTML5的开源图标库-ECharts
- POI操作Excel表
- ubuntu12.04 jdk1.7 安装
- Solution to Failed to find "glu32" in "" with CMAKE_CXX_LIBRARY_ARCHITECTURE ""
- VS2008中打印九九表
- 标准I/O
- 基于二叉树和数组实现限制长度的最优Huffman编码
- 关于extjs的分页