resources
其他网址
Apache Maven Resources Plugin插件详解_成长的足迹-CSDN博客
maven之<build> <resources> <resource> 详细介绍_涂作权的博客-CSDN博客
Maven学习笔记(十二)-maven打包之resource配置_fendo-CSDN博客_maven resources
Maven 资源文件（Resources）的打包（package）与过滤（filter）_zsensei的博客-CSDN博客
简介
maven默认的处理流程
- java：src/main/java和src/test/java
这两个目录中的所有*.java文件会分别在comile和test-comiple阶段被编译，编译结果分别放到了target/classes和targe/test-classes目录中，但是这两个目录中的其他文件都会被忽略掉。- resources：src/main/resouces和src/test/resources
这两个目录中的文件也会分别被复制到target/classes和target/test-classes目录中。- target：target/classes
打包插件默认会把这个目录中的所有内容打入到jar包或者war包中。
Apache Maven Resources Plugin
Apache Maven Resources Plugin是Apache Maven团队提供的官方核心插件，能够将Maven项目中的各种资源文件复制到指定的输出目录中。此插件是默认就带的，无需引入。
1. 在Maven项目中的资源可以分为两类
- main资源，指位于src/main/resources路径下的资源文件
- test资源，指位于src/test/resources路径下的资源文件
2. Apache Maven Resources Plugin提供的Goals
1) resources:resources
将main资源文件复制到输出目录，默认已经加入到Maven的process-resources生命周期阶段。
- <project><build><resources>指定要复制的main资源文件，默认位于src/main/resources路径
- <project><build><outputDirectory>指定main资源的输出目录，默认位于target/classes/路径
2) resources:testResources
将test资源文件复制到输出目录，默认已经加入到Maven的process-test-resources生命周期阶段。
- <project><build><testResources>指定要复制的test资源文件，默认位于src/test/resources路径
- <project><build><testOutputDirectory>指定test资源的输出目录，默认位于target/test-classes/路径
3) resources:copy-resources
对于非main资源或非test资源，又没有在pom.xml的<build><resources>...</build></resources>配置的资源，在构建过程中不会输出到项目的target/classes/目录下。
<resource> <targetPath>META-INF/plexus</targetPath> <!--- <filtering>false</filtering> ---> <directory>${basedir}/src/main/plexus</directory> <includes> <include>configuration.xml</include> </includes> <excludes> <exclude>**/*.properties</exclude> </excludes> </resource>targetPath：指定打包后放到哪个目录，默认是base directory。
filtering：指定是否将filter文件(即上面说的filters里定义的*.property文件)的变量值在这个resource文件有效，例如上面就指定那些变量值在configuration文件无效。
directory：指定属性文件的目录，build的过程需要找到它，并且将其放到targetPath下，默认的directory是${basedir}/src/main/resources
includes：指定包含文件的patterns,符合样式并且在directory目录下的文件将会包含进project的资源文件。
excludes：指定不包含在内的patterns。如果inclues与excludes有冲突，那么excludes胜利，那些符合冲突的样式的文件是不会包含进来的。
filtering详解
指定资源文件
其他网址
简介
如果我们的资源不在默认的路径下边，那么就要手动去指定它。方法如下：
- 设置build/resources
- 使用maven-resources-plugin插件
- 使用build-helper-maven-plugin插件
示例1：既使用父项目（parent指定）的resources路径，又使用本项目的resources路径
在父项目的pom.xml里添加此配置：
<build> <resources> <resource> <directory>src/main/resources</directory> <includes> <include>**/*</include> </includes> <filtering>false</filtering> </resource> <resource> <directory>../base/src/main/resources</directory> <includes> <include>**/*</include> </includes> <filtering>false</filtering> </resource> </resources> </build>
示例2：不同方法打包src/main/java下边的*.xml文件
Mybatis的xxx.xml文件，我们习惯把它和Mapper.java放一起，都在src/main/java下面。默认情况下这些文件是不会打包的，因为只会打包serc/main/java下边的xxx.java文件(maven认为src/main/java只是java的源代码路径)。因此，我们就要指定xxx.xml文件位置。
注意：下边只写了添加src/main/java的配置方法，设置之后resources会只有这一个。所以，应该把原来的路径也添加上：src/main/resources。
build/resources
<build> <!---> 省略其他内容 <---> <resources> <resource> <directory>src/main/java</directory> <includes> <include>**/*.xml</include> </includes> <filtering>false</filtering> </resource> </resources> </build>
maven-resources-plugins
<build> <!---> 省略其他内容 <---> </plugins> <plugin> <artifactId>maven-resources-plugin</artifactId> <version>2.5</version> <executions> <execution> <id>copy-xmls</id> <phase>process-sources</phase> <goals> <goal>copy-resources</goal> </goals> <configuration> <outputDirectory>${basedir}/target/classes</outputDirectory> <resources> <resource> <directory>${basedir}/src/main/java</directory> <includes> <include>**/*.xml</include> </includes> </resource> </resources> </configuration> </execution> </executions> </plugin> </plugins> </build>
build-helper-maven-plugin
<build> <!---> 省略其他内容 <---> </plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>build-helper-maven-plugin</artifactId> <version>1.8</version> <executions> <execution> <id>add-resource</id> <phase>generate-resources</phase> <goals> <goal>add-resource</goal> </goals> <configuration> <resources> <resource> <directory>src/main/java</directory> <includes> <include>**/*.xml</include> </includes> </resource> </resources> </configuration> </execution> </executions> </plugin> </plugins> </build>
plugins
maven-resources-plugin
其他网址
Apache Maven Resources Plugin插件详解_成长的足迹-CSDN博客
<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>extensions
true or false, 决定是否要load这个plugin的extensions，默认为true。
inherited
是否让子pom继承，ture or false，默认为true
configuration
配置。通常用于私有不开源的plugin。
dependencies
与pom基础的dependencies的结构和功能都相同，只是plugin的dependencies用于plugin,而pom的denpendencies用于项目本身。在plugin的dependencies主要用于改变plugin原来的dependencies，例如排除一些用不到的dependency或者修改dependency的版本等，详细请看pom的denpendencies.
executions
plugin也有很多个目标，每个目标具有不同的配置，executions就是设定plugin的目标，
<execution> <id>echodir</id> <goals> <goal>run</goal> </goals> <phase>verify</phase> <inherited>false</inherited> <configuration> <tasks> <echo>Build Dir: ${project.build.directory}</echo> </tasks> </configuration> </execution>id：标识符
goals：里面列出一系列的goals元素，例如上面的run goal
phase：声明goals执行的时期，例如：verify
inherited：是否传递execution到子pom里，默认为true。
configuration：设置execution下列表的goals的设置，而不是plugin所有的goals的设置
实例
增加src/main/java下边的*.xml文件。
<build> <!---> 省略其他内容 <---> </plugins> <plugin> <artifactId>maven-resources-plugin</artifactId> <version>2.5</version> <executions> <execution> <id>copy-xmls</id> <phase>process-sources</phase> <goals> <goal>copy-resources</goal> </goals> <configuration> <outputDirectory>${basedir}/target/classes</outputDirectory> <resources> <resource> <directory>${basedir}/src/main/java</directory> <includes> <include>**/*.xml</include> </includes> </resource> </resources> </configuration> </execution> </executions> </plugin> </plugins> </build>
build-helper-maven-plugin
其他网址
Maven配置源代码和资源目录_yh_zeng2的博客-CSDN博客
maven指定多个源码目录_影子的博客-CSDN博客_maven 指定目录
需求
有父工程（base）和多个子工程，父工程里有公用的工具类和配置类，子工程要使用它。
写法
<build> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>build-helper-maven-plugin</artifactId> <version>1.8</version> <executions> <execution> <id>add-source</id> <phase>generate-sources</phase> <goals> <goal>add-source</goal> </goals> <configuration> <sources> <source>src/main/java</source> <source>../base</source> </sources> </configuration> </execution> </executions> </plugin> </plugins> </build>然后，子项目把base源码加入Spring的扫描范围即可。比如product子项目，在启动类上添加注解：
@SpringBootApplication(scanBasePackages={"com.example.product", "com.example.base"})
注：上边写的<source>../base</source>是为了在显示时比较好看，会把base和本项目并排在一起，如下图所示：
如果这么写：<source>../base/src/main/java</source> ，显示如下（从java路径开始并排）：
这两种写法只会影响显示效果。对代码没有任何影响，比如，子项目的注解都用这种：
@SpringBootApplication(scanBasePackages={"com.example.product", "com.example.base"})
注意：以下写法是不可以的，它只能指定一个源码路径
<build> <!--默认源代码目录 --> <sourceDirectory>src/main/java</sourceDirectory> <!-- ${project.build.directory}就是我们通常看到的target目录 --> <outputDirectory>${project.build.directory}/classes</outputDirectory> <!--默认测试源代码目录 --> <testSourceDirectory>src/test/java</testSourceDirectory> <testOutputDirectory>${project.build.directory}/test-classes </testOutputDirectory> <!--默认资源目录 --> <resources> <resource> <directory>src/main/resources</directory> <excludes> <exclude>**/*.java</exclude> </excludes> </resource> </resources> <!--默认测试资源目录 --> <testResources> <testResource> <directory>src/test/resources</directory> <excludes> <exclude>**/*.java</exclude> </excludes> </testResource> </testResources> </build>
其他
defaultGoal: 默认的目标，必须跟命令行上的参数相同，如：jar:jar,或者与时期parse相同,例如install
directory: 指定build target目标的目录，默认为$(basedir}/target,即项目根目录下的target
finalName: 指定生成的去掉后缀的工程（包）名字，默认为${artifactId}-${version}。
filters: 用于定义指定filter属性的位置，例如filter元素赋值filters/filter1.properties,那么这个文件里面就可以定义name=value对，这个name=value对的值就可以在工程pom中通过${name}引用，默认的filter目录是${basedir}/src/main/fiters/
testResources: 测试资源元素，与resources类似，默认的测试资源路径是${basedir}/src/test/resources,测试资源是不部署的。
pluginManagement：类似于denpendencyManagement。只是denpendencyManagement是用于管理项目jar包依赖，pluginManagement是用于管理plugin。与pom build里的plugins区别是，这里的plugin是列出来，然后让子pom来决定是否引用。