利用Profile构建不同环境的部署包

阅读更多

项目开发好以后，通常要在多个环境部署，象我们公司多达5种环境：本机环境(local)、(开发小组内自测的)开发环境(dev)、(提供给测试团队的)测试环境(test)、预发布环境(pre)、正式生产环境(prod)，每种环境都有各自的配置参数，比如：数据库连接、远程调用的ws地址等等。如果每个环境build前手动修改这些参数，显然太不fashion.

maven早就考虑到了这些问题，看下面的pom片段：

 1 
 2         
 3             
 4             local
 5                             
 6                 jdbc:oracle:thin:@localhost:1521:XE
 7                 ***
 8                 ***
 9             
10         
11         
12             
13             dev
14                             
15                 jdbc:oracle:thin:@172.21.129.51:1521:orcl
16                 ***
17                 ***
18             
19             
20             
21                 true
22             
23         
24         ...
25     

profiles节点中，定义了二种环境：local、dev(默认激活dev环境)，可以在各自的环境中添加需要的property值，接下来修改build节点，参考下面的示例：


复制代码
1
2        
3            
4                 src/main/resources
5                 true
6            
7        
8        
9            
10                 org.apache.maven.plugins
11                 maven-compiler-plugin
12                 2.5.1
13                
14                     1.6
15                     1.6
16                     utf-8
17                
18            
19        
20    
复制代码
resource节点是关键，它表明了哪个目录下的配置文件（不管是xml配置文件，还是properties属性文件），需要根据profile环境来替换属性值。

通常配置文件放在resources目录下，build时该目录下的文件都自动会copy到class目录下



以上图为例，其中spring-database.xml的内容为：


复制代码
1
2 3     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
4     xsi:schemaLocation="http://www.springframework.org/schema/beans
5     http://www.springframework.org/schema/beans/spring-beans.xsd">
6
7     8         class="org.springframework.jdbc.datasource.DriverManagerDataSource">
9        
10        
11        
12                
13    
14
复制代码
各属性节点的值，用占位符"${属性名}"占位，maven在package时，会根据profile的环境自动替换这些占位符为实际属性值。

默认情况下：

maven package

将采用默认激活的profile环境来打包，也可以手动指定环境，比如：

maven package -P dev

将自动打包成dev环境的部署包(注：参数P为大写)



最后再给2个实例的运用例子：

1、开发环境与生产环境数据源采用不同方式的问题

本机开发时为了方便，很多开发人员喜欢直接用JDBC直接连接数据库，这样修改起来方便；


复制代码
1     2         destroy-method="close">
3        
4        
5        
6        
7        
8        
9        
10        
11    
复制代码
而生产环境，通常是在webserver(比如weblogic上)配置一个JNDI数据源，


1    
2                
3    
如果每次发布生产前，都要手动修改，未免太原始，可以通过maven的profile来解决

先把配置文件改成


复制代码
1     2         destroy-method="close">
3        
4        
5        
6        
7        
8        
9        
10        
11    
12    
13    
14                
15    
复制代码
即用占位符来代替bean的id，然后在pom.xml里类似下面设置


复制代码
1               
2            
3             local
4            
5                 ...
6                 dataSource
7                 NONE
8                 jdbc:oracle:thin:@172.21.129.51:1521:orcl               
9                 mu_fsu
10                 mu_fsu
11                 ...
12            
13            
14            
15                 true
16            
17                
18        
19            
20             pro
21            
22                 ...
23                 NONE
24                 dataSource
25                 ...
26            
27        
28    
复制代码
这样，mvn clean package -P local打包本地开发环境时，将生成


复制代码
1     2         destroy-method="close">
3        
4        
5        
6        
7        
8        
9        
10        
11    
12    
13    
14                
15    
复制代码
而打包生产环境 mvn clean package -P pro时，生成


复制代码
1     2         destroy-method="close">
3        
4        
5        
6        
7        
8        
9        
10        
11    
12    
13    
14                
15    
复制代码
spring配置的其它跟数据库相关的bean，约定引用dataSource这个名称的bean即可



2、不同webserver环境，依赖jar包，是否打包的问题

weblogic上，允许多个app，把共用的jar包按约定打包成一个war文件，以library的方式部署，然后各应用在WEB-INF/weblogic.xml中，用类似下面的形式


复制代码
1
2
3     ...
4    
5         my-share-lib
6    
7
复制代码
指定共享library 的名称即可。这样的好处是，即节省了服务器开销，而且各app打包时，就不必再重复打包这些jar文件，打包后的体积大大减少，上传起来会快很多。

而其它webserver上却未必有这个机制，一般为了方便，我们开发时，往往采用一些轻量级的webserver，比如:tomcat,jetty,jboss 之类，正式部署时才发布到weblogic下，这样带来的问题就是，本机打包时，要求这些依赖jar包，全打包到app的WEB-INF/lib下；而生产环境下，各应用的WEB-INF/lib下并不需要这些jar文件，同样还是用profile来搞定，先处理pom.xml，把依赖项改成类似下面的形式：


复制代码
1        
2             dom4j
3             dom4j
4             1.6.1
5             ${jar.scope}
6        
复制代码
即scope这里，用一个占位符来代替，然后profile这样配置


复制代码
1        
2            
3             local
4            
5                 compile
6                 ...
7            
8            
9            
10                 true
11            
12        
13        
14            
15             pro
16            
17                 provided
18                 ...
19            
20        
复制代码
在maven里，如果一个依赖项的scope是provided，表示由容器提供，打包时将不会打包进最终的package里，所以这样配置后，生产环境打包时，依赖项的scope全变成了provided，即不打包进war文件，而本机环境下，因为scope是compile，所以会打包到war里

作者：菩提树下的杨过
出处：http://yjmyzz.cnblogs.com