Maven 学习总结 （七） 之 灵活构建

　　一个优秀的构建系统必须足够灵活，他应该能够让项目在不同的环境下都能成功地构建。Maven为支持项目的灵活性，内置了三大特性，即属性、Profile和资源过滤。

Maven属性

　　

通过<properties>元素用户可以自定义一个或多个属性，然后在POM中通过${属性名称}的方式进行引用，这中做法的最大意义在于消除重复。

Maven的6类属性：

　　- 内置属性，

　　　　　　　　${basedir}表示根目录，即包含pom.xml文件的目录；

　　　　　　　　${version} 表示项目版本。

　　- POM属性，用户可以使用该类属性引用POM文件中对应元素的值。

　　　　　　　　${project.build.sourceDirectory}：项目的主源码目录，默认为src/main/java

　　　　　　　　${project.build.testSourceDirectory}：项目的测试源码目录，默认为src/test/java

　　　　　　　　${project.build.directory}：项目构建输出目录，默认为target/

　　　　　　　　${project.outputDirectory}：项目主代码编译输出目录，默认为target/classes

　　　　　　　　${project.testOutputDirectory}：项目测试代码编译输出目录，默认为target/test-classes

　　　　　　　　${project.groupId}：项目的groupId

　　　　　　　　${project.artifactId}：项目的artifactId

　　　　　　　　${project.version}：项目的version，与${version}等价

　　　　　　　　${project.build.finalName}：项目打包输出的名字，默认为${project.artifactId}-${project.version}

　　- 自定义属性，用户可以在POM的<properties>元素下自定义Maven属性。

　　- Settings属性，与POM属性相同，用户可以使用以settings.开头的属性引用setting.xml文件中的XML元素的值。如常用的${settings.localRepository}指向用户本地仓库的地址。

　　- Java系统属性，所有Java系统属性都可以使用Maven属性引用，例如${user.home}指向了用户目录。用户可以使用mvn help:system查看所有的java系统属性。

　　- 环境变量，所有环境变量都可使用env.开头的Maven属性引用。例如${env.JAVA_HOME}指向了JAVA_HOME环境变量值。用户可以使用mvn help: system查看所有的环境变量。

Maven属性能让我们在POM中方便地引用项目目录和构建环境的各种十分有用的值，这是创建灵活构建的基础。正确使用这些Maven属性可以帮助我们简化POM的配置和维护工作。

资源过滤

　　为了应对环境的变化，首先需要使用Maven属性将一些会发生变化的部分提取出来。例如数据库配置容易发生变化，因此用Maven 属性取代他们：

　　数据库配置文件：

　　

　　4个Maven属性db.driver、db.url、db.username、db.password。既然使用Maven，就应该在某个地方定义他们。除了在<properties>中自定义Maven属性，还可以使用额外的profile将其包裹

　　<profiles>

　　　　<profile>

　　　　　　<id>dev</id>

　　　　　　<properties>

　　　　　　　　<db.driver>com.mysql.jdbc.Driver</db.driver>

　　　　　　　　<db.url>jdbc:mysql://192.168.1.100:3306/test</db.url>

　　　　　　　　<db.username>dev</db.username>

　　　　　　　　<db.password>dev-pwd</db.password>

　　　　　　</properties>

　　　　</profile>

　　</profiles>

以上Maven属性定义与直接在POM中的properties元素下定义并无二致，这里只是使用了一个id为dev的profile。其目的是将开发环境下的配置与其他环境区别开来。

　　有了属性定义，可以在配置文件中使用这些属性了吗？还不行，Maven属性默认只有在POM中才会被解析，在src/main/resources目录下的文件中属性，构建的时候它将仍然还是${db.username}。

资源文件的处理其实是maven-resources-plugin做的事情，它默认的行为只是将项目主资源文件复制到主代码编译输出目录中，将测试资源文件复制到测试低吗编译输出目录中。不过

只要通过一些简单的POM配置，该插件就能够解析资源文件中的maven属性。即开启资源过滤。

　　Maven默认的主资源目录和测试资源目录定义在超级POM中。要为资源目录开启过滤，只要在此基础上添加一行filtering配置即可

　　为主资源目录开启过滤：

　　

　　为测试资源目录开过滤：

　　

以上主资源目录和测试资源目录都可超过一个，虽然会破坏Maven的约定，但Maven允许用户声明多个资源目录，并为每个资源目录提供不同的过滤配置。

到目前为止一切基本就绪，我们将数据库配置的变化部分提取成了Maven属性，在POM的profile中定义了这些属性的值，并为资源目录开启了属性过滤。最后，只需要

在命令行激活profile 。Maven就能够在构建项目的时候用profile中的属性值替换数据库配置文件中的属性引用。

　　

Maven Profile

　　为了能让构建在各个环境下方便地一直，Maven引入了profile的概念。profile能够在构建的时候修改POM的一个自己，或者添加额外的配置元素。用户可以使用很多方式激活profile.

以实现构建在不同环境下的移植。

　　　　　　

　　　　　　

激活profile，为了尽可能方便用户，Maven支持很多种激活Profile的方式：

　　- 命令行激活

　　　　用户可以使用mvn命令行参数-P加上profile id来激活profile，多个id之间以逗号分隔。

　　　　

　　- settings文件显示激活

　　　　如果用户希望某个profile默认一直处于激活状态，可以配置settings.xml文件的active-Profiles元素，表示其配置的profile对于所有项目都处于激活状态

　　　　

　

　- 系统属性激活

　　　　用户可以配置当前某系统属性存在的时候，自动激活一个关于仓库配置的profile

　　　　

　　　　可以进一步配置当某系统属性test存在，且等于x的时候激活profile

　　　　

　　用户可以在命令行声明系统属性。例如，

　　

　　这其实是一种从命令行激活profile的方法，而且多个profile完全可以使用同一个系统属性来激活。

　　- 操作系统环境激活

　　如果构建在不同的操作系统有差异，用户完全可以将这些差异写进profile，然后配置他们自动基于操作系统环境激活。

　　

　　- 文件存在与否激活

　　maven能够根据文件存在与否决定是否激活profile

　　

　　- 默认激活　　

　　用户可以在定义profile的时候指定其默认激活

　　　　

使用activeByDefault元素用户可以指定profile自动激活，如果有多个profile，他们的激活方式各异用户如何知道哪些profile被激活了？

　　

Profile种类，

　　- pom.xml，很显然，pom.xml中声明的profile只对当前项目有效。

　　- 用户settings.xml，用户目录下 .m2/settings.xml中的profile对本机上所有的Maven项目有效。

　　- 全局settings.xml，Maven安装目录下conf/settings.xml对本机上所有的Maven项目有效。

　　- profiles.xml（Maven2），还可以在项目根目录下使用额外的profiles.xml文件来声明profile，不过该特性被Maven3移除了。建议用户将这类profile移到settings.xml中。

　　不同类型的profile可以声明的POM元素是不同的。pom.xml中的profile能够随着pom.xml一起被提交到代码仓库中、被Maven安装到本地仓库中、被部署到远程Maven仓库中。

该profile伴随着pom.xml一直存在。因此他可以修改或者增加很多POM元素。POM中profile可使用的元素：

　　

　　其他三种外部的profile，由于无法保证他们能够随着特定pom.xml被分发，因此不允许他们添加或者修改绝大多数的pom元素。外部profile只能声明如下的几个元素：

　　

 Web资源过滤

　　在Web项目中，资源文件位于src/main/resources/目录下，他们经处理后会位于WAR包的WEB-INF/classes目录下，这也是java代码编译打包后的目录。也就是说这类资源

文件在打包后位于应用程序的classpath中。Web项目还有另外一类资源文件，默认他们源码位于src/main/webapp/目录，经打包后位于WAR包的根目录。例如，一个Web项目

的css源码文件在src/main/webapp/css/目录，项目打包后可以在WAR包的css/目录下找到对应的css文件。这类资源文件称作web资源文件，他们自打包后不在应用程序的classpath中。

　　与一般的资源文件一样，web资源文件默认不会被过来。开启一般资源文件的过滤不会影响到web资源文件。

　　如果希望在构建项目的时候，为不同的客户使用不一样的资源文件。这时可以在web资源文件中使用Maven属性如${client.theme}等，然后使用profile分别定义这些Maven属性

的值。

　　

　　然后配置maven-war-plugin对src/main/webapp/ 这一web资源目录开启过滤：

　　

　　声明了web资源目录src/main/webapp，然后配置filtering开启过滤，并且使用includes指定要过滤的文件，这里是所有css和js文件。配置完成后，可以选择激活某个profile。