前言：
<build >设置，主要用于编译设置
在Maven的pom.xml文件中，存在如下两种<build>：
（1）全局配置（project build）
针对整个项目的所有情况都有效
（2）配置（profile build）
针对不同的profile配置
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
...
<!-- "Project Build" contains elements of the BaseBuild set and the Build set-->
<build>...</build>
<profiles>
<profile>
<!-- "Profile Build" contains elements of the BaseBuild set only -->
<build>...</build>
</profile>
</profiles>
</project>
说明：
一种<build>被称为Project Build，即是<project>的直接子元素。
另一种<build>被称为Profile Build，即是<profile>的直接子元素。
Profile Build包含了基本的build元素，而Project Build还包含两个特殊的元素，即各种<...Directory>和<extensions>。
示例如下
<build>
<defaultGoal>install</defaultGoal>
<directory>${basedir}/target</directory>
<finalName>${artifactId}-${version}</finalName>
<filters>
<filter>filters/filter1.properties</filter>
</filters>
...
</build>
1）defaultGoal
执行build任务时，如果没有指定目标，将使用的默认值。
如上配置：在命令行中执行mvn，则相当于执行mvn install
2）directory
build目标文件的存放目录，默认在${basedir}/target目录
3）finalName
build目标文件的名称，默认情况为${artifactId}-${version}
4）filter
定义*.properties文件，包含一个properties列表，该列表会应用到支持filter的resources中。
也就是说，定义在filter的文件中的name=value键值对，会在build时代替${name}值应用到resources中。
maven的默认filter文件夹为${basedir}/src/main/filters
用于包含或者排除某些资源文件
<build>
...
<resources>
<resource>
<targetPath>META-INF/plexus</targetPath>
<filtering>true</filtering>
<directory>${basedir}/src/main/plexus</directory>
<includes>
<include>configuration.xml</include>
</includes>
<excludes>
<exclude>**/*.properties</exclude>
</excludes>
</resource>
</resources>
<testResources>
...
</testResources>
...
</build>
1）resources
一个resources元素的列表。每一个都描述与项目关联的文件是什么和在哪里
2）targetPath
指定build后的resource存放的文件夹，默认是basedir。
通常被打包在jar中的resources的目标路径是META-INF
3）filtering
true/false，表示为这个resource，filter是否激活
4）directory
定义resource文件所在的文件夹，默认为${basedir}/src/main/resources
5）includes
指定哪些文件将被匹配，以*作为通配符
6）excludes
指定哪些文件将被忽略
7）testResources
定义和resource类似，只不过在test时使用
目前在开发一个wap项目，主要有开发、测试和最终部署上线几个阶段，每个阶段对配置（数据库、日志）都有不同的设置。以前都是以开发环境为主，在测试和部署上线时由部署工程师负责修改配置并上线。但是公司并非都有一个项目，我们也不是只负责一个项目，这样的工作方式导致每每上线时大家都心惊胆颤，实在忍受不了折磨，决定研究下maven下如何解决这个问题。找到方案后，不敢独享，将结果向大家介绍下。思路：
几个环境中主要的不同可以概括为数据库配置和log日志路径配置以及外部依赖的接口配置不一样，但是我们这里简单起见，假设只考虑数据库配置。
这样的话，如果能实现在生成不同的发布包时对资源进行不同的替换就可以达到目的了。经过研究maven，确定了最终方案。最终方案：
首先需要在pom文件中确定filter和要filter的资源，这是通过在build节点中添加filter和resource来实现的，示例如下：
<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下的资源进行过滤，因为该目录下没有二进制文件，所以没有excluding。过滤时采用的过滤文件为src/main/filters/filter-${env}.properties文件，其中${env}是一个变量，表示当前使用的环境，这是通过在pom文件中通过profile定义的，如下所示：
<properties>
<env>dev</env>
</properties>
<profiles>
<profile>
<id>dev</id>
<properties>
<env>dev</env>
</properties>
</profile>
<profile>
<id>test</id>
<properties>
<env>test</env>
</properties>
</profile>
<profile>
<id>product</id>
<properties>
<env>product</env>
</properties>
</profile>
</profiles>
其中斜体字部分表示缺省的变量值，这样在开发时就不用每次指定这个值。在测试和部署上线时分别通过-P传入当前的profile id，这样maven就会将env变量设置为对应的值，从而导致使用不同的filter文件来对resources下的文件进行过滤替换。
例如：当调用maven package时传入-Pdev（因为我们将dev设置为默认，所以也可以不传）参数，则会使用
filter-dev.properties中的内容来替换resources目录中的配置文件，具体到我们的项目就是db.properties,内容如下：
....... jdbc.connection.url=${xiangmu.jdbc.url} jdbc.connection.username=${xiangmu.jdbc.username} jdbc.connection.password=${xiangmu.jdbc.password} ............... filter-dev.properties文件内容如下：
................ xiangmu.jdbc.url=jdbc:mysql://localhost:3306/xiangmu?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8 xiangmu.jdbc.username=root xiangmu.jdbc.password=abcdefg ................. 这样在编译结束后
db.properties的内容就会变为： jdbc.connection.url=jdbc:mysql://localhost:3306/xiangmu?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8 jdbc.connection.username=root jdbc.connection.password=abcdefg
用于指定使用的插件
<build>
...
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.0</version>
<extensions>false</extensions>
<inherited>true</inherited>
<configuration>
<classifier>test</classifier>
</configuration>
<dependencies>...</dependencies>
<executions>...</executions>
</plugin>
</plugins>
</build>
pluginManagement的配置和plugins的配置是一样的，只是用于继承，使得可以在孩子pom中使用。
父pom：
<build>
...
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.2</version>
<executions>
<execution>
<id>pre-process-classes</id>
<phase>compile</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<classifier>pre-process</classifier>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
...
</build>
则在子pom中，我们只需要配置：
<build>
...
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
</plugin>
</plugins>
...
</build>
这样大大简化了孩子pom的配置