Maven
文章目录MavenMaven仓库1.局域网仓库Maven管理springboot配置1.Maven配置管理（properties属性值引用pom标签值）2.properties-maven-plugin（properties引用其它文件内容）3.多种环境配置1.用不同的值填充properties文件2.选用不同的properties文件作为启动配置文件Maven在IDEA的使用1.生命周期Mave
·
文章目录
Maven
java项目中往往需要添加很多依赖jar包，一般情况下我们需要找到并下载jar、然后添加到项目中，这很不方便，通过使用maven，只需要写一段目标jar的maven信息，即可自动引入jar。
这里的jar被项目依赖，因此可称为项目依赖、坐标等。
Maven仓库
1.局域网仓库
局域网未连接外网，需要配置中央仓库，maven项目的pom.xml实际上有一个父pom，里面配置了一个默认的远程仓库。
- repositories：依赖仓库。
- pluginRepositories：插件仓库。
<!--依赖仓库-->
<repositories>
<repository>
<id>central</id>
<name>Central Repository</name>
<url>https://repo.maven.apache.org/maven2</url>
<layout>default</layout>
<snapshots>
<enabled>false</enabled> <!--是否下载snapshots版本构件-->
</snapshots>
</repository>
</repositories>
在你项目的pom中，你可以配置多个仓库，包括局域网仓库，当你在自身的pom中配置仓库时，你会发现这个配置只在当前pom中生效，如果你有多个pom时怎么办呢，而且setting不直接支持上面的标签。
使用profiles标签可以实现仓库全局配置：
<profiles>
<!--开发环境-->
<profile>
<id>dev</id>
<!-- 此环境配置默认使用 -->
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<repositories>
<repository>
<id>myRepository</id>
<url>仓库地址</url>
</repository>
</repositories>
</profile>
</profiles>
Maven管理springboot配置
在springboot项目中存在很多如yml、properties、xml这样的项目配置文件，当配置文件不止一个且有相同内容时,需要将值统一管理，实际配置中只做引用，打包时再进行填充。
列举2个使用场景：
- 多环境配置时有多个配置文件。
- 模块化开发时不同模块可能存在相同配置，统一管理方便修改。
1.Maven配置管理（properties属性值引用pom标签值）
maven中提供了一个配置管理方案，只需将指定值放在pom.xml标签中,配置文件中属性通过 ${标签名} 或者 @标签名@ 来引用即可。
properties内容：
dbc.driverClassName=${jdbc.driverClassName}
jdbc.url=${jdbc.url}
jdbc.username=${jdbc.username}
jdbc.password=${jdbc.password}
pom.xml内容：
项目配置文件的格式可以是properties、yml、xml等，< properties >用来在pom.xml中声明属性值，子标签名为自定义变量。
<!--属性值配置-->
<properties>
<jdbc.driverClassName>com.mysql.jdbc.Driver</jdbc.driverClassName>
<jdbc.url>jdbc:mysql://localhost/ssm?...</jdbc.url>
<jdbc.username>root</jdbc.username>
<jdbc.password>root</jdbc.password>
</properties>
<!--项目构建配置-->
<build>
<!--资源文件打包配置，指明需要打包的配置文件，并填充文件中的maven变量-->
<resources>
<!--指定打包-->
<resource>
<filtering>true</filtering><!--是否开启过滤-->
<directory>${project.basedir}/src/main/resources</directory><!--资源文件所在目录${project.basedir}定位到项目子目录-->
<includes><!--要打包的文件-->
<include>*.properties</include>
</includes>
</resource>
<!--排除打包-->
<resource>
<filtering>false</filtering>
<directory>${project.basedir}/src/main/resources</directory>
<excludes><!--要排除打包的文件-->
<exclude>*.properties</exclude>
</excludes>
</resource>
</resources>
</build>
不使用filtering、excludes以及includes标签时，默认将指定路径下的所有文件都打包，名称相同的文件内容取并集。
resource子标签介绍：
- directory：声明项目配置文件所在目录。
- targetPath：打包后的文件所在目录。
- filtering：是否开启过滤
- includes：指定打包文件。
- exclude：指定不打包文件。
2.properties-maven-plugin（properties引用其它文件内容）
通过maven自带的配置管理，可以将属性值放在pom.xm中，但配置的属性值过多时，将造成pom.xml中内容冗长，所以需要将值存放在别处，如一个文件中。properties-maven-plugin插件正好可以解决这个问题。
properties-maven-plugin插件对文件格式要求：
- 项目配置文件：没做要求，符合项目的配置格式即可。
- 存属性值的文件：内容格式必须为： 变量=值 的格式，文件后缀可以随意，内容格式符合即可（推荐properties）。
下面使用yml作为项目配置文件来示例：
1.创建一个存放属性值的文件：my.ini (为了凸显没限制才用ini后缀，实际项目中最好用properties后缀)
2.创建项目配置文件：application.yml，并引用my.ini里的值
注意：soux我们希望application.yml中的属性引用my.ini的属性值8083，但上面这样做无法直接引入，因此我们需要用到此插件来指明他们的关系。
插件使用：
首先我们需要指明存放属性值的文件：build标签下
<plugins><!--插件列表-->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-2</version>
<executions>
<execution>
<id>default-cli</id>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files><!--指定存放属性值的文件-->
<file>${project.basedir}/src/main/resources/my.ini</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
然后我们显式声明配置文件的位置( build标签下 )，如果不声明，就无法填充配置文件变量值：
<resources>
<resource>
<directory>${project.basedir}/src/main/resources</directory><!--目录-->
<filtering>true</filtering>
<includes>
<include>application.yml</include><!--要打包的文件-->
</includes>
</resource>
</resources>
上面的配置只打包了项目配置文件，my.ini文件将不会被打包，因为该文件不需要被打包，为什么呢？因为在打包时maven将值填充到项目配置文件中，打包之后该配置文件值不再是变量，而是实际值。
注意：
上面的引用是支持多级引用的：
b=1、a= ${b}、c= ${a}，结果将是a=b=c=1
3.多种环境配置
在项目中存在多种环境，如开发环境、测试环境、生产环境，往往在不同环境中采用不同的配置，如果直接修改项目配置文件会很麻烦，因此可以创建多个环境的项目配置文件，然后根据不同环境来选择使用。
1.用不同的值填充properties文件
根据选择的环境不同，在填充项目配置文件中的${ }或@ @时，选择不同的pom属性值配置或不同的存放实际属性值的文件，来实现多环境配置的效果。
以不使用插件举例。使用标签profiles和profile来划分不同环境的配置：
<profiles>
<!--开发环境-->
<profile>
<id>dev</id>
<properties>
<server-port>8088</server-port>
</properties>
<activation> <!-- 声明默认使用的环境 -->
<activeByDefault>true</activeByDefault>
</activation>
</profile>
<!--生产环境-->
<profile>
<id>pre</id>
<properties>
<server-port>9099</server-port>
</properties>
</profile>
</profiles>
上面添加了2个环境的信息，显示声明项目配置文件后就可以将指定环境的属性值填充进去了。
显式声明将项目配置文件打包：
<build>
<!--填充指定配置文件的变量，并将该文件添加到打包-->
<resources>
<resource>
<filtering>true</filtering>
<directory>${project.basedir}/src/main/resources/</directory>
</resource>
</resources>
</build>
上面配置了2种环境的配置，profile标签代表一个环境的配置，内部甚至可以根据环境来配置不同的项目依赖。
此时使用maven命令：mvn clean install -P环境ID 即可将指定环境的值填充到项目配置文件的引用位置。
另外，在IDEA中我们可以快速选择指定环境打包项目：
选择对应的环境，编译并重启，对于环境的属性值就会被填充到配置文件的变量位置。
关于插件：
首先要明白一点，pom中定义的标签，自身是可以直接引用的。
如果属性值没有在pom中配置，而是在其它文件中配置，我们只需要在pom中配置一个属性标签就可以选择文件来填充项目配置文件的引用了。当然前提是你存放属性实际值的文件要根据环境划分好。
下面就以一个dev环境举例：<profile> <id>dev</id> <properties> <hj>dev</hj> <!--自定义标签：声明属性值文件时使用--> </properties> </profile>使用插件声明存放配置值的文件时：
<plugin> ... <executions> <execution> ... <configuration> <files><!--指定存放属性值的文件--> <file>${project.basedir}/src/main/resources/${hj}.ini</file> </files> </configuration> </execution> </executions> </plugin>当我以dev环境编译时，< hj >中的属性值生效，并在实际值文件声明部分替换文件名，从而使项目配置文件中的引用被dev.ini填充。
2.选用不同的properties文件作为启动配置文件
通过上面一小节可以发现，选择存放实际值的文件时将文件名替换为hj的值即可，我们可以在声明打包时的配置文件时也可以这样做：
<resource>
<directory>${project.basedir}/src/main/resources</directory>
<filtering>true</filtering>
<includes>
<include>${hj}.properties</include>
</includes>
</resource>
假设环境为dev，此时打包项目后，target目录下的配置文件仅有dev.properties，但却无法启动，因为springboot中默认的配置文件名为application。
如何让这个文件生效呢？ 其实很容易，方法有多种，下面列2种。
方法一：文件改名，只需要做如下2步：
1.文件名前面添加"application-":
光看文件图标就能看出明显不一样了。
2.将application.properties也打包，内容指定开发环境，即-后面的部分，内容可以通过pom中的hj标签值指定：
经过上面2步后，pom中的打包配置变成了这样：<resource> <directory>${project.basedir}/src/main/resources</directory> <filtering>true</filtering> <includes> <include>application-${hj}.properties</include> <include>application.properties</include> </includes> </resource>运行项目后就发现可以使用不同环境的配置了。
方法二：不改名。
1.将配置文件放在不同文件夹下：
2.声明打包：
美滋滋，只要你会，你还能玩得更花。
其实只需要读懂pom的3块地方你就能轻松读懂上面的内容：
- resources标签：指定打包的配置文件
- profile标签：一个环境的配置内容，多个此标签相互独立。
- plugin标签：插件，此篇使用的插件用来指出属性值实际存放文件的位置。
4.模块化开发、父子项目配置
此章节主要讲模块化开发的配置部分，具体模块化开发请看的我另一篇博客：https://blog.csdn.net/qq_52681418/article/details/114395970
在大型项目中，为了降低项目的耦合性，我们需要进行模块化开发，即将server、serverimpl、controller、dao、bean进行拆分，形成父子项目（子项目指模块）。
模块化开发目录如下：
在此模式下，每个子模块都是一个独立的小项目，每个小项目都有自己的配置文件和pom，我们统一来管理配置的值也变得稍微复杂一点，但这仍然不难。
全局属性值配置文件
我们在父项目下创建一个config文件夹，里面存放我们的所有子项目配置的实际值文件，分别填充每个子项目的applicatin.properties
上面的文件是多个环境的配置，它们相当于前面讲的.ini文件，此处规范化。
可以发现它们存放在父项目下，子项目继承父项目，自然可以使用它们。因此我们可以使用它们来填充每个子项目中的application.properties中的${ }或@@
子pom配置properties-maven-plugin插件
前面学习到，配置文件引用其它文件需要使用properties-maven-plugin插件，因此我们的子项目引用父项目的文件也是如此。
此处注意：
- ${project.basedir}：当前项目根目录，子项目引用时将是子项目根目录。
- ${project.parent.basedir}：当前项目的父项目根目录。
- ${user.dir}：用户创建的根项目的根目录。
子项目只需要配置插件，并指定配置源为父项目config目录下的文件即可。
1.指定配置文件值的存放位置
<plugin><!--properties-maven-plugin：使文件引入另一个文件的配置--> <groupId>org.codehaus.mojo</groupId> <artifactId>properties-maven-plugin</artifactId> <version>1.0-alpha-2</version> <executions> <execution> <id>default-cli</id> <phase>initialize</phase> <goals> <goal>read-project-properties</goal> </goals> <configuration> <files><!--此处指向父项目下的配置--> <file>${project.parent.basedir}/config/${hj}.properties</file> </files> </configuration> </execution> </executions> </plugin>2.然后我们需要显式声明打包的配置文件：
<resource> <filtering>true</filtering> <directory>${project.basedir}/src/main/resources</directory> <includes> <include>*.properties</include> </includes> </resource>3.由于使用了环境，所有我们还需要环境部分：环境有多个，此处只举1个为例：
<profile> <id>dev</id> <properties> <hj>dev</hj> <!--自定义标签：声明属性值文件时使用--> </properties> </profile>接下来只需要在每个子项目进行上面的配置，就可以使用了。
全局pom配置
我想你应该看出来了，如果在每个子项目的pom都进行如上配置，这无疑是灾难性的。我们得想办法去除这些重复的配置，真么办呢？
首先我们需要了解父子pom的关系：
- 子pom继承父pom，子pom将直接使用父pom的内容
- 两个pom之间相同的部分，子pom将在子项目中覆盖父pom
子项目继承父项目，子pom继承父pom，我们只需要将子pom中的配置迁移到父pom就可以了，迁移的方法如下：
1.关于环境的profiles标签：整个项目的环境必定是统一的，直接将其移到父pom即可。
2.关于打包的resources标签：子项目和父项目都将打包自身配置，因此也直接迁移。
3.关于配置文件位置的配置：我们也直接迁移，但会发现出错如下：
报错的原因很明显，因为已经在父项目了，再指向父项目将会报错。
聪明的你肯定会想到改为下面的配置：直接引用当前项目的目录。
完美！！！但是你编译时却发现，他竟然报错了！！！what？？？？
父项目编译正常，第一个子项目都不通过，此时再看右侧的说明：
本应该是父项目根目录\config的路径在编译模块时变成了子项目根目录\config，这是为什么呢？
其实，子pom继承父pom，在打包时，子pom中将直接引用父pom配置，此过程将不会填充 $ {}，因此相当于在子项目中指定为${project.basedir}。此时自然表示子项目根目录，由于子项目不存在该文件，故而报错。
那么该如何解决呢？子pom覆盖父pom，其实我们只需要添加一个属性即可：
如果你边看边改项目，这小小节先暂停一下，看完再改。
1.父项目做如下配置：
<properties> <configDir>${project.basedir}</configDir> </properties>2.每个子项目做如下配置：
<properties> <configDir>${project.parent.basedir}</configDir> </properties>3.父项目配置插件：
<plugin><!--properties-maven-plugin：使文件引入另一个文件的配置--> <groupId>org.codehaus.mojo</groupId> <artifactId>properties-maven-plugin</artifactId> <version>1.0-alpha-2</version> <executions> <execution> <id>default-cli</id> <phase>initialize</phase> <goals> <goal>read-project-properties</goal> </goals> <configuration> <files><!--指定不同环境配置文件属性值的实际存放文件位置--> <file>${configDir}/config/${hj}.properties</file> </files> </configuration> </execution> </executions> </plugin>由于父、子项目都有自身独立的configDir属性值，所以在编译时将按照自身的标签值来指定配置文件的根路径，因此每次的将是正确的。
关于父子项目配置：最终插件的迁移目录问题的解决办法是自己临时想出来的，虽然不是最优的方案，但它是根据自己的思路来寻找解决思路，这说明两天的辛苦也没算白费。
此篇博客一直紧跟我的思路，到现在已经填了不少坑，不敢说文章毫无瑕疵，但沿着我的文章阅读+实践，你也可以轻松使用maven来管理配置。
重量级补充!!!
上面的设置需要在父项目及每个模块中添加一个configDir标签，虽然较之前好很多，但始终感觉是一个疙瘩。于是我继续寻找解决办法，最后终于找到了，使用 ${user.dir} 即可（此变量指向用户的创建的最顶层根目录），也就是说关于插件这一块的配置直接就能迁移了。
<plugin><!--properties-maven-plugin：使文件引入另一个文件的配置--> <groupId>org.codehaus.mojo</groupId> <artifactId>properties-maven-plugin</artifactId> <version>1.0-alpha-2</version> <executions> <execution> <id>default-cli</id> <phase>initialize</phase> <goals> <goal>read-project-properties</goal> </goals> <configuration> <files><!--指定不同环境配置文件属性值的实际存放文件位置--> <file>${user.dir}/config/${hj}.properties</file> </files> </configuration> </execution> </executions> </plugin>既然找到了问题，为什么不删除前面的，直接使用${user.dir}来教程呢？保留的原因如下：
- 让读者理解整个思路，使学习的知识更加牢固。
- 一些有一定基础的人可能只是寻求解决方案，他们的项目可能更加复杂多变，上面的旧方案虽然不是很好，但可以解决更复杂的场景出现的问题，或者为遇到问题的人提供解决思路。
- 作者懒。
Maven在IDEA的使用
1.生命周期
- clean：移除所有上一次构建生成的文件。会删除target目录，不会删除本地的maven仓库的jar文件。
- validate：验证工程是否正确，所需的信息是否完整。
- compile：将选定目标编译成class文件。
- test：单元测试。
- package：将项目打包为jar或war到自身的target目录下，如果被其他项目依赖，则需要使用install添加到仓库。
- verify：检查package是否有效、符合标准。
- install：将项目打包为jar并将jar添加到本地仓库（默认仓库路径为/.m2）。
- build：功能类似compile，不过只对整个项目进行编译。
- site：生成项目的站点文档
- deploy：复制到远程仓库
pom.xml配置大全
下面xml来源：https://blog.csdn.net/xingbaozhen1210/article/details/81867358
<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.0http://maven.apache.org/maven-v4_0_0.xsd">
<!-- 父项目的坐标 . 如果项目中没有规定某个元素的值 , 那么父项目中的对应值即为项目的默认值 . 坐标包括group ID , artifact ID和 version . -->
<parent>
<artifactId>com.xbz</artifactId><!-- 被继承的父项目的构件标识符 -->
<groupId>parent</groupId><!-- 被继承的父项目的全球唯一标识符 -->
<version>1.0.0</version><!-- 被继承的父项目的版本 -->
<relativePath>../pom.xml</relativePath><!-- 父项目的pom.xml文件的相对路径 . 相对路径允许你选择一个不同的路径 . 默认值是../pom.xml . Maven首先在构建当前项目的地方寻找父项 目的pom , 其次在文件系统的这个位置（relativePath位置） , 然后在本地仓库 , 最后在远程仓库寻找父项目的pom . -->
</parent>
<modelVersion>4.0.0</modelVersion><!-- 声明项目描述符遵循哪一个POM模型版本 . 模型本身的版本很少改变 , 虽然如此 , 但它仍然是必不可少的 , 这是为了当Maven引入了新的特性或者其他模型变更的时候 , 确保稳定性 . -->
<groupId>asia.banseon</groupId><!-- 项目的全球唯一标识符 , 通常使用全限定的包名区分该项目和其他项目 . 并且构建时生成的路径也是由此生成 , 如com.mycompany.app生成的相对路径为：/com/mycompany/app -->
<artifactId>banseon-maven2
</artifactId><!-- 构件的标识符 , 它和group ID一起唯一标识一个构件 . 换句话说 , 你不能有两个不同的项目拥有同样的artifact ID和groupID；在某个 特定的group ID下 , artifact ID也必须是唯一的 . 构件是项目产生的或使用的一个东西 , Maven为项目产生的构件包括：JARs , 源 码 , 二进制发布和WARs等 . -->
<packaging>jar</packaging><!-- 项目产生的构件类型 , 例如jar, war, ear, pom . 插件可以创建他们自己的构件类型 , 所以前面列的不是全部构件类型 -->
<version>1.0-SNAPSHOT</version><!-- 项目当前版本 , 格式为:主版本.次版本.增量版本-限定版本号 -->
<name>banseon-maven</name><!-- 项目的名称, Maven产生的文档用 -->
<url>http://www.baidu.com/banseon</url><!-- 项目主页的URL, Maven产生的文档用 -->
<description>A maven project to study maven.
</description><!-- 项目的详细描述, Maven 产生的文档用 . 当这个元素能够用HTML格式描述时（例如 , CDATA中的文本会被解析器忽略 , 就可以包含HTML标 签） , 不鼓励使用纯文本描述 . 如果你需要修改产生的web站点的索引页面 , 你应该修改你自己的索引页文件 , 而不是调整这里的文档 . -->
<!-- 描述了这个项目构建环境中的前提条件 . -->
<prerequisites>
<maven>2.0.3</maven><!-- 构建该项目或使用该插件所需要的Maven的最低版本 -->
</prerequisites>
<!-- 项目的问题管理系统(Bugzilla, Jira, Scarab,或任何你喜欢的问题管理系统)的名称和URL , 本例为 jira -->
<issueManagement>
<system>jira</system><!-- 问题管理系统（例如jira）的名字 , -->
<url>http://my.jira.com/banseon</url><!-- 该项目使用的问题管理系统的URL -->
</issueManagement>
<!-- 项目持续集成信息 -->
<ciManagement>
<system></system><!-- 持续集成系统的名字 , 例如continuum -->
<url></url><!-- 该项目使用的持续集成系统的URL（如果持续集成系统有web接口的话） . -->
<!-- 构建完成时 , 需要通知的开发者/用户的配置项 . 包括被通知者信息和通知条件（错误 , 失败 , 成功 , 警告） -->
<notifiers>
<!-- 配置一种方式 , 当构建中断时 , 以该方式通知用户/开发者 -->
<notifier>
<type></type><!-- 传送通知的途径 -->
<sendOnError></sendOnError><!-- 发生错误时是否通知 -->
<sendOnFailure></sendOnFailure><!-- 构建失败时是否通知 -->
<sendOnSuccess></sendOnSuccess><!-- 构建成功时是否通知 -->
<sendOnWarning></sendOnWarning><!-- 发生警告时是否通知 -->
<address></address><!-- 不赞成使用 . 通知发送到哪里 -->
<configuration></configuration><!-- 扩展配置项 -->
</notifier>
</notifiers>
</ciManagement>
<inceptionYear></inceptionYear><!-- 项目创建年份 , 4位数字 . 当产生版权信息时需要使用这个值 . -->
<!-- 项目相关邮件列表信息 -->
<mailingLists>
<!-- 该元素描述了项目相关的所有邮件列表 . 自动产生的网站引用这些信息 . -->
<mailingList>
<name>XMail</name><!-- 邮件的名称 -->
<post>xingxbz@163.com</post><!-- 发送邮件的地址或链接 , 如果是邮件地址 , 创建文档时 , mailto: 链接会被自动创建 -->
<subscribe>xingxbz@163.com</subscribe><!-- 订阅邮件的地址或链接 , 如果是邮件地址 , 创建文档时 , mailto: 链接会被自动创建 -->
<unsubscribe>xingxbz@163.com</unsubscribe><!-- 取消订阅邮件的地址或链接 , 如果是邮件地址 , 创建文档时 , mailto: 链接会被自动创建 -->
<archive>http:/xingmail.com/demo/mail/</archive><!-- 你可以浏览邮件信息的URL -->
</mailingList>
</mailingLists>
<!-- 项目开发者列表 -->
<developers>
<!-- 某个项目开发者的信息 -->
<developer>
<id>DEV 001</id><!-- SCM里项目开发者的唯一标识符 -->
<name>Xingbz</name><!-- 项目开发者的全名 -->
<email>xingxbz@163.com</email><!-- 项目开发者的email -->
<url>https://blog.csdn.net/xingbaozhen1210</url><!-- 项目开发者的主页的URL -->
<!-- 项目开发者在项目中扮演的角色 , 角色元素描述了各种角色 -->
<roles>
<role>Manager</role>
<role>Test</role>
<role>Dev</role>
</roles>
<organization>xbz</organization><!-- 项目开发者所属组织 -->
<organizationUrl>https://blog.csdn.net/xingbaozhen1210</organizationUrl><!-- 项目开发者所属组织的URL -->
<!-- 项目开发者属性 , 如即时消息如何处理等 -->
<properties>
<dept>No</dept>
</properties>
<timezone>+8</timezone><!-- 项目开发者所在时区 , -11到12范围内的整数 . -->
</developer>
</developers>
<!-- 项目的其他贡献者列表 -->
<contributors>
<!-- 项目的其他贡献者 . 参见developers/developer元素 -->
<contributor>
<name></name>
<email></email>
<url></url>
<organization></organization>
<organizationUrl></organizationUrl>
<roles></roles>
<timezone></timezone>
<properties></properties>
</contributor>
</contributors>
<!-- 该元素描述了项目所有License列表 . 应该只列出该项目的license列表 , 不要列出依赖项目的 license列表 . 如果列出多个license , 用户可以选择它们中的一个而不是接受所有license . -->
<licenses>
<!-- 描述了项目的license , 用于生成项目的web站点的license页面 , 其他一些报表和validation也会用到该元素 . -->
<license>
<name>Xbz Projet</name><!-- license用于法律上的名称 -->
<url>https://blog.csdn.net/xingbaozhen1210</url><!-- 官方的license正文页面的URL -->
<distribution>repo</distribution><!-- 项目分发的主要方式： repo , 可以从Maven库下载 manual , 用户必须手动下载和安装依赖 -->
<comments>ABCDEFG...</comments><!-- 关于license的补充信息 -->
</license>
</licenses>
<!-- SCM(Source Control Management)标签允许你配置你的代码库 , 供Maven web站点和其它插件使用 . -->
<scm>
<connection>scm:svn:http://svn.baidu.com/banseon/maven/banseon/banseon-maven2-trunk(dao-trunk)
</connection><!-- SCM的URL,该URL描述了版本库和如何连接到版本库 . 欲知详情 , 请看SCMs提供的URL格式和列表 . 该连接只读 . -->
<developerConnection>scm:svn:http://svn.baidu.com/banseon/maven/banseon/dao-trunk</developerConnection><!-- 给开发者使用的 , 类似connection元素 . 即该连接不仅仅只读 -->
<tag></tag><!-- 当前代码的标签 , 在开发阶段默认为HEAD -->
<url>http://svn.baidu.com/banseon</url><!-- 指向项目的可浏览SCM库（例如ViewVC或者Fisheye）的URL . -->
</scm>
<!-- 描述项目所属组织的各种属性 . Maven产生的文档用 -->
<organization>
<name>demo</name><!-- 组织的全名 -->
<url>http://www.baidu.com/banseon</url><!-- 组织主页的URL -->
</organization>
<!-- 构建项目需要的信息 -->
<build>
<sourceDirectory></sourceDirectory><!-- 该元素设置了项目源码目录 , 当构建项目的时候 , 构建系统会编译目录里的源码 . 该路径是相对于pom.xml的相对路径 . -->
<scriptSourceDirectory></scriptSourceDirectory><!-- 该元素设置了项目脚本源码目录 , 该目录和源码目录不同：绝大多数情况下 , 该目录下的内容 会被拷贝到输出目录(因为脚本是被解释的 , 而不是被编译的) . -->
<testSourceDirectory></testSourceDirectory><!-- 该元素设置了项目单元测试使用的源码目录 , 当测试项目的时候 , 构建系统会编译目录里的源码 . 该路径是相对于pom.xml的相对路径 . -->
<outputDirectory></outputDirectory><!-- 被编译过的应用程序class文件存放的目录 . -->
<testOutputDirectory></testOutputDirectory><!-- 被编译过的测试class文件存放的目录 . -->
<!-- 使用来自该项目的一系列构建扩展 -->
<extensions>
<!-- 描述使用到的构建扩展 . -->
<extension>
<groupId></groupId><!-- 构建扩展的groupId -->
<artifactId></artifactId><!-- 构建扩展的artifactId -->
<version></version><!-- 构建扩展的版本 -->
</extension>
</extensions>
<defaultGoal></defaultGoal><!-- 当项目没有规定目标（Maven2 叫做阶段）时的默认值 -->
<!-- 这个元素描述了项目相关的所有资源路径列表 , 例如和项目相关的属性文件 , 这些资源被包含在最终的打包文件里 . -->
<resources>
<!-- 这个元素描述了项目相关或测试相关的所有资源路径 -->
<resource>
<targetPath></targetPath><!-- 描述了资源的目标路径 . 该路径相对target/classes目录（例如${project.build.outputDirectory}） . 举个例 子 , 如果你想资源在特定的包里(org.apache.maven.messages) , 你就必须该元素设置为org/apache/maven /messages . 然而 , 如果你只是想把资源放到源码目录结构里 , 就不需要该配置 . -->
<filtering></filtering><!-- 是否使用参数值代替参数名 . 参数值取自properties元素或者文件里配置的属性 , 文件在filters元素里列出 . -->
<directory></directory><!-- 描述存放资源的目录 , 该路径相对POM路径 -->
<includes></includes><!-- 包含的模式列表 , 例如**/*.xml. -->
<excludes></excludes><!-- 排除的模式列表 , 例如**/*.xml -->
</resource>
</resources>
<!-- 这个元素描述了单元测试相关的所有资源路径 , 例如和单元测试相关的属性文件 . -->
<testResources>
<!-- 这个元素描述了测试相关的所有资源路径 , 参见build/resources/resource元素的说明 -->
<testResource>
<targetPath></targetPath>
<filtering></filtering>
<directory></directory>
<includes></includes>
<excludes></excludes>
</testResource>
</testResources>
<directory></directory><!-- 构建产生的所有文件存放的目录 -->
<finalName></finalName><!-- 产生的构件的文件名 , 默认值是${artifactId}-${version} . -->
<filters></filters><!-- 当filtering开关打开时 , 使用到的过滤器属性文件列表 -->
<!-- 子项目可以引用的默认插件信息 . 该插件配置项直到被引用时才会被解析或绑定到生命周期 . 给定插件的任何本地配置都会覆盖这里的配置 -->
<pluginManagement>
<!-- 使用的插件列表 . -->
<plugins>
<!-- plugin元素包含描述插件所需要的信息 . -->
<plugin>
<groupId></groupId><!-- 插件在仓库里的group ID -->
<artifactId></artifactId><!-- 插件在仓库里的artifact ID -->
<version></version><!-- 被使用的插件的版本（或版本范围） -->
<extensions></extensions><!-- 是否从该插件下载Maven扩展（例如打包和类型处理器） , 由于性能原因 , 只有在真需要下载时 , 该元素才被设置成enabled . -->
<!-- 在构建生命周期中执行一组目标的配置 . 每个目标可能有不同的配置 . -->
<executions>
<!-- execution元素包含了插件执行需要的信息 -->
<execution>
<id></id><!-- 执行目标的标识符 , 用于标识构建过程中的目标 , 或者匹配继承过程中需要合并的执行目标 -->
<phase></phase><!-- 绑定了目标的构建生命周期阶段 , 如果省略 , 目标会被绑定到源数据里配置的默认阶段 -->
<goals></goals><!-- 配置的执行目标 -->
<inherited></inherited><!-- 配置是否被传播到子POM -->
<configuration></configuration><!-- 作为DOM对象的配置 -->
</execution>
</executions>
<!-- 项目引入插件所需要的额外依赖 -->
<dependencies>
<!-- 参见dependencies/dependency元素 -->
<dependency>
......
</dependency>
</dependencies>
<inherited></inherited><!-- 任何配置是否被传播到子项目 -->
<configuration></configuration><!-- 作为DOM对象的配置 -->
</plugin>
</plugins>
</pluginManagement>
<!-- 使用的插件列表 -->
<plugins>
<!-- 参见build/pluginManagement/plugins/plugin元素 -->
<plugin>
<groupId></groupId>
<artifactId></artifactId>
<version></version>
<extensions></extensions>
<executions>
<execution>
<id></id>
<phase></phase>
<goals></goals>
<inherited></inherited>
<configuration></configuration>
</execution>
</executions>
<dependencies>
<!-- 参见dependencies/dependency元素 -->
<dependency>
......
</dependency>
</dependencies>
<goals></goals>
<inherited></inherited>
<configuration></configuration>
</plugin>
</plugins>
</build>
<!-- 在列的项目构建profile , 如果被激活 , 会修改构建处理 -->
<profiles>
<!-- 根据环境参数或命令行参数激活某个构建处理 -->
<profile>
<id></id><!-- 构建配置的唯一标识符 . 即用于命令行激活 , 也用于在继承时合并具有相同标识符的profile . -->
<!-- 自动触发profile的条件逻辑 . Activation是profile的开启钥匙 . profile的力量来自于它
能够在某些特定的环境中自动使用某些特定的值；这些环境通过activation元素指定 . activation元素并不是激活profile的唯一方式 . -->
<activation>
<activeByDefault></activeByDefault><!-- profile默认是否激活的标志 -->
<jdk></jdk><!-- 当匹配的jdk被检测到 , profile被激活 . 例如 , 1.4激活JDK1.4 , 1.4.0_2 , 而!1.4激活所有版本不是以1.4开头的JDK . -->
<!-- 当匹配的操作系统属性被检测到 , profile被激活 . os元素可以定义一些操作系统相关的属性 . -->
<os>
<name>Windows 7</name><!-- 激活profile的操作系统的名字 -->
<family>Windows</family><!-- 激活profile的操作系统所属家族(如 'windows') -->
<arch>x64</arch><!-- 激活profile的操作系统体系结构 -->
<version>7.2.3580</version><!-- 激活profile的操作系统版本 -->
</os>
<!-- 如果Maven检测到某一个属性（其值可以在POM中通过${名称}引用） , 其拥有对应的名称和值 , Profile就会被激活 . 如果值
字段是空的 , 那么存在属性名称字段就会激活profile , 否则按区分大小写方式匹配属性值字段 -->
<property>
<name>mavenVersion</name><!-- 激活profile的属性的名称 -->
<value>2.0.3</value><!-- 激活profile的属性的值 -->
</property>
<!-- 提供一个文件名 , 通过检测该文件的存在或不存在来激活profile . missing检查文件是否存在 , 如果不存在则激活
profile . 另一方面 , exists则会检查文件是否存在 , 如果存在则激活profile . -->
<file>
<exists>/usr/local/xbz/workspace/</exists><!-- 如果指定的文件存在 , 则激活profile . -->
<missing>/usr/local/xbz/workspace/</missing><!-- 如果指定的文件不存在 , 则激活profile . -->
</file>
</activation>
<!-- 构建项目所需要的信息 . 参见build元素 -->
<build>
<defaultGoal></defaultGoal>
<resources>
<resource>
<targetPath></targetPath>
<filtering></filtering>
<directory></directory>
<includes></includes>
<excludes></excludes>
</resource>
</resources>
<testResources>
<testResource>
<targetPath></targetPath>
<filtering></filtering>
<directory></directory>
<includes></includes>
<excludes></excludes>
</testResource>
</testResources>
<directory></directory>
<finalName></finalName>
<filters></filters>
<pluginManagement>
<plugins>
<!-- 参见build/pluginManagement/plugins/plugin元素 -->
<plugin>
<groupId></groupId>
<artifactId></artifactId>
<version></version>
<extensions></extensions>
<executions>
<execution>
<id></id>
<phase></phase>
<goals></goals>
<inherited></inherited>
<configuration></configuration>
</execution>
</executions>
<dependencies>
<!-- 参见dependencies/dependency元素 -->
<dependency>
......
</dependency>
</dependencies>
<goals></goals>
<inherited></inherited>
<configuration></configuration>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<!-- 参见build/pluginManagement/plugins/plugin元素 -->
<plugin>
<groupId></groupId>
<artifactId></artifactId>
<version></version>
<extensions></extensions>
<executions>
<execution>
<id></id>
<phase></phase>
<goals></goals>
<inherited></inherited>
<configuration></configuration>
</execution>
</executions>
<dependencies>
<!-- 参见dependencies/dependency元素 -->
<dependency>
......
</dependency>
</dependencies>
<goals></goals>
<inherited></inherited>
<configuration></configuration>
</plugin>
</plugins>
</build>
<modules></modules><!-- 模块（有时称作子项目） 被构建成项目的一部分 . 列出的每个模块元素是指向该模块的目录的相对路径 -->
<!-- 发现依赖和扩展的远程仓库列表 . -->
<repositories>
<!-- 参见repositories/repository元素 -->
<repository>
<releases>
<enabled></enabled>
<updatePolicy></updatePolicy>
<checksumPolicy></checksumPolicy>
</releases>
<snapshots>
<enabled></enabled>
<updatePolicy></updatePolicy>
<checksumPolicy></checksumPolicy>
</snapshots>
<id></id>
<name></name>
<url></url>
<layout></layout>
</repository>
</repositories>
<!-- 发现插件的远程仓库列表 , 这些插件用于构建和报表 -->
<pluginRepositories>
<!-- 包含需要连接到远程插件仓库的信息.参见repositories/repository元素 -->
<pluginRepository>
<releases>
<enabled></enabled>
<updatePolicy></updatePolicy>
<checksumPolicy></checksumPolicy>
</releases>
<snapshots>
<enabled></enabled>
<updatePolicy></updatePolicy>
<checksumPolicy></checksumPolicy>
</snapshots>
<id></id>
<name></name>
<url></url>
<layout></layout>
</pluginRepository>
</pluginRepositories>
<!-- 该元素描述了项目相关的所有依赖 . 这些依赖组成了项目构建过程中的一个个环节 . 它们自动从项目定义的仓库中下载 . 要获取更多信息 , 请看项目依赖机制 . -->
<dependencies>
<!-- 参见dependencies/dependency元素 -->
<dependency>
......
</dependency>
</dependencies>
<reports></reports><!-- 不赞成使用. 现在Maven忽略该元素. -->
<!-- 该元素包括使用报表插件产生报表的规范 . 当用户执行“mvn site” , 这些报表就会运行 . 在页面导航栏能看到所有报表的链接 . 参见reporting元素 -->
<reporting>
......
</reporting>
<!-- 参见dependencyManagement元素 -->
<dependencyManagement>
<dependencies>
<!-- 参见dependencies/dependency元素 -->
<dependency>
......
</dependency>
</dependencies>
</dependencyManagement>
<!-- 参见distributionManagement元素 -->
<distributionManagement>
......
</distributionManagement>
<!-- 参见properties元素 -->
<properties/>
</profile>
</profiles>
<!-- 模块（有时称作子项目） 被构建成项目的一部分 . 列出的每个模块元素是指向该模块的目录的相对路径 -->
<modules></modules>
<!-- 发现依赖和扩展的远程仓库列表 . -->
<repositories>
<!-- 包含需要连接到远程仓库的信息 -->
<repository>
<!-- 如何处理远程仓库里发布版本的下载 -->
<releases>
<enabled></enabled><!-- true或者false表示该仓库是否为下载某种类型构件（发布版 , 快照版）开启 . -->
<updatePolicy></updatePolicy><!-- 该元素指定更新发生的频率 . Maven会比较本地POM和远程POM的时间戳 . 这里的选项是：always（一直） , daily（默认 , 每日） , interval：X（这里X是以分钟为单位的时间间隔） , 或者never（从不） . -->
<checksumPolicy></checksumPolicy><!-- 当Maven验证构件校验文件失败时该怎么做：ignore（忽略） , fail（失败） , 或者warn（警告） . -->
</releases>
<!-- 如何处理远程仓库里快照版本的下载 . 有了releases和snapshots这两组配置 , POM就可以在每个单独的仓库中 , 为每种类型的构件采取不同的 策略 . 例如 , 可能有人会决定只为开发目的开启对快照版本下载的支持 . 参见repositories/repository/releases元素 -->
<snapshots>
<enabled></enabled>
<updatePolicy></updatePolicy>
<checksumPolicy></checksumPolicy>
</snapshots>
<id>banseon-repository-proxy</id><!-- 远程仓库唯一标识符 . 可以用来匹配在settings.xml文件里配置的远程仓库 -->
<name>banseon-repository-proxy</name><!-- 远程仓库名称 -->
<url>http://127.0.0.1:8888/repository/</url><!-- 远程仓库URL , 按protocol://hostname/path形式 -->
<layout>default</layout><!-- 用于定位和排序构件的仓库布局类型-可以是default（默认）或者legacy（遗留） . Maven 2为其仓库提供了一个默认的布局；然 而 , Maven 1.x有一种不同的布局 . 我们可以使用该元素指定布局是default（默认）还是legacy（遗留） . -->
</repository>
</repositories>
<!-- 发现插件的远程仓库列表 , 这些插件用于构建和报表 -->
<pluginRepositories>
<!-- 包含需要连接到远程插件仓库的信息.参见repositories/repository元素 -->
<pluginRepository>
......
</pluginRepository>
</pluginRepositories>
<!-- 该元素描述了项目相关的所有依赖 . 这些依赖组成了项目构建过程中的一个个环节 . 它们自动从项目定义的仓库中下载 . 要获取更多信息 , 请看项目依赖机制 . -->
<dependencies>
<dependency>
<groupId>org.apache.maven</groupId><!-- 依赖的group ID -->
<artifactId>maven-artifact</artifactId><!-- 依赖的artifact ID -->
<version>3.8.1</version><!-- 依赖的版本号 . 在Maven 2里, 也可以配置成版本号的范围 . -->
<type>jar</type><!-- 依赖类型 , 默认类型是jar . 它通常表示依赖的文件的扩展名 , 但也有例外 . 一个类型可以被映射成另外一个扩展名或分类器 . 类型经常和使用的打包方式对应 , 尽管这也有例外 . 一些类型的例子：jar , war , ejb-client和test-jar . 如果设置extensions为 true , 就可以在 plugin里定义新的类型 . 所以前面的类型的例子不完整 . -->
<classifier></classifier><!-- 依赖的分类器 . 分类器可以区分属于同一个POM , 但不同构建方式的构件 . 分类器名被附加到文件名的版本号后面 . 例如 , 如果你想要构建两个单独的构件成 JAR , 一个使用Java 1.4编译器 , 另一个使用Java 6编译器 , 你就可以使用分类器来生成两个单独的JAR构件 . -->
<scope>test</scope><!-- 依赖范围 . 在项目发布过程中 , 帮助决定哪些构件被包括进来 . 欲知详情请参考依赖机制 .
- compile ：默认范围 , 用于编译
- provided：类似于编译 , 但支持你期待jdk或者容器提供 , 类似于classpath
- runtime: 在执行时需要使用
- test: 用于test任务时使用
- system: 需要外在提供相应的元素 . 通过systemPath来取得
- systemPath: 仅用于范围为system . 提供相应的路径
- optional: 当项目自身被依赖时 , 标注依赖是否传递 . 用于连续依赖时使用 -->
<systemPath></systemPath><!-- 仅供system范围使用 . 注意 , 不鼓励使用这个元素 , 并且在新的版本中该元素可能被覆盖掉 . 该元素为依赖规定了文件系统上的路径 . 需要绝对路径而不是相对路径 . 推荐使用属性匹配绝对路径 , 例如${java.home} . -->
<!-- 当计算传递依赖时 , 从依赖构件列表里 , 列出被排除的依赖构件集 . 即告诉maven你只依赖指定的项目 , 不依赖项目的依赖 . 此元素主要用于解决版本冲突问题 -->
<exclusions>
<exclusion>
<artifactId>spring-core</artifactId>
<groupId>org.springframework</groupId>
</exclusion>
</exclusions>
<optional>true</optional><!-- 可选依赖 , 如果你在项目B中把C依赖声明为可选 , 你就需要在依赖于B的项目（例如项目A）中显式的引用对C的依赖 . 可选依赖阻断依赖的传递性 . -->
</dependency>
</dependencies>
<reports></reports><!-- 不赞成使用. 现在Maven忽略该元素. -->
<!-- 该元素描述使用报表插件产生报表的规范 . 当用户执行“mvn site” , 这些报表就会运行 . 在页面导航栏能看到所有报表的链接 . -->
<reporting>
<excludeDefaults></excludeDefaults><!-- true , 则 , 网站不包括默认的报表 . 这包括“项目信息”菜单中的报表 . -->
<outputDirectory></outputDirectory><!-- 所有产生的报表存放到哪里 . 默认值是${project.build.directory}/site . -->
<!-- 使用的报表插件和他们的配置 . -->
<plugins>
<!-- plugin元素包含描述报表插件需要的信息 -->
<plugin>
<groupId></groupId><!-- 报表插件在仓库里的group ID -->
<artifactId></artifactId><!-- 报表插件在仓库里的artifact ID -->
<version></version><!-- 被使用的报表插件的版本（或版本范围） -->
<inherited></inherited><!-- 任何配置是否被传播到子项目 -->
<configuration></configuration><!-- 报表插件的配置 -->
<!-- 一组报表的多重规范 , 每个规范可能有不同的配置 . 一个规范（报表集）对应一个执行目标 . 例如 , 有1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9个报表 . 1 , 2 , 5构成A报表集 , 对应一个执行目标 . 2 , 5 , 8构成B报表集 , 对应另一个执行目标 -->
<reportSets>
<!-- 表示报表的一个集合 , 以及产生该集合的配置 -->
<reportSet>
<id></id><!-- 报表集合的唯一标识符 , POM继承时用到 -->
<configuration></configuration><!-- 产生报表集合时 , 被使用的报表的配置 -->
<inherited></inherited><!-- 配置是否被继承到子POMs -->
<reports></reports><!-- 这个集合里使用到哪些报表 -->
</reportSet>
</reportSets>
</plugin>
</plugins>
</reporting>
<!-- 继承自该项目的所有子项目的默认依赖信息 . 这部分的依赖信息不会被立即解析,而是当子项目声明一个依赖（必须描述group ID和 artifact ID信息） , 如果group ID和artifact ID以外的一些信息没有描述 , 则通过group ID和artifact ID 匹配到这里的依赖 , 并使用这里的依赖信息 . -->
<dependencyManagement>
<dependencies>
<!-- 参见dependencies/dependency元素 -->
<dependency>
......
</dependency>
</dependencies>
</dependencyManagement>
<!-- 项目分发信息 , 在执行mvn deploy后表示要发布的位置 . 有了这些信息就可以把网站部署到远程服务器或者把构件部署到远程仓库 . -->
<distributionManagement>
<!-- 部署项目产生的构件到远程仓库需要的信息 -->
<repository>
<uniqueVersion></uniqueVersion><!-- 是分配给快照一个唯一的版本号（由时间戳和构建流水号）？还是每次都使用相同的版本号？参见repositories/repository元素 -->
<id>banseon-maven2</id>
<name>banseon maven2</name>
<url>file://${basedir}/target/deploy</url>
<layout></layout>
</repository>
<!-- 构件的快照部署到哪里？如果没有配置该元素 , 默认部署到repository元素配置的仓库 , 参见distributionManagement/repository元素 -->
<snapshotRepository>
<uniqueVersion></uniqueVersion>
<id>banseon-maven2</id>
<name>Banseon-maven2 Snapshot Repository</name>
<url>scp://svn.baidu.com/banseon:/usr/local/maven-snapshot</url>
<layout></layout>
</snapshotRepository>
<!-- 部署项目的网站需要的信息 -->
<site>
<id>banseon-site</id><!-- 部署位置的唯一标识符 , 用来匹配站点和settings.xml文件里的配置 -->
<name>business api website</name><!-- 部署位置的名称 -->
<url>scp://svn.baidu.com/banseon:/var/www/localhost/banseon-web</url><!-- 部署位置的URL , 按protocol://hostname/path形式 -->
</site>
<downloadUrl></downloadUrl><!-- 项目下载页面的URL . 如果没有该元素 , 用户应该参考主页 . 使用该元素的原因是：帮助定位那些不在仓库里的构件（由于license限制） . -->
<!-- 如果构件有了新的group ID和artifact ID（构件移到了新的位置） , 这里列出构件的重定位信息 . -->
<relocation>
<groupId></groupId><!-- 构件新的group ID -->
<artifactId></artifactId><!-- 构件新的artifact ID -->
<version></version><!-- 构件新的版本号 -->
<message></message><!-- 显示给用户的 , 关于移动的额外信息 , 例如原因 . -->
</relocation>
<status></status><!-- 给出该构件在远程仓库的状态 . 不得在本地项目中设置该元素 , 因为这是工具自动更新的 . 有效的值有：none（默认） , converted（仓库管理员从 Maven 1 POM转换过来） , partner（直接从伙伴Maven 2仓库同步过来） , deployed（从Maven 2实例部 署） , verified（被核实时正确的和最终的） . -->
</distributionManagement>
<!-- 以值替代名称 , Properties可以在整个POM中使用 , 也可以作为触发条件（见settings.xml配置文件里activation元素的说明） . 格式是<name>value</name> . -->
<properties>
<version1>1.0</version1>
<version2>2.0</version2>
</properties>
</project>
CSDN联合极客时间，共同打造面向开发者的精品内容学习社区，助力成长！
更多推荐
1
0- 0
已为社区贡献1条内容
所有评论(0)