1、POM文件详解
POM是项目对象模型（Project Object Model）的简称
setting.xml主要用于配置maven的运行环境等一系列通用的属性，是全局级别的配置文件；
而pom.xml主要描述了项目的maven坐标，该文件用于管理：源代码、配置文件、开发者的信
息和角色、问题追踪系统、组织信息、项目授权、项目的url、项目的依赖关系等等。是项目级别的配置文件。
<modelVersion>：pom版本标签：必须标签，表示是一个固定的版本，指定了当前pom的版本
<parent>：指明项目的父POM
<groupId>：坐标信息标签 ：<基础设置> 公司或者组织的唯一标志，通常使用全限定的包名区分该项目和其他项目。并且构建时生成的路径也是由此生成，如x.xx.xxx生成的相对路径为：/x/xx/xxx/ 。可定义为：com.xquant.xcrms
<artifactId>：本项目的唯一ID：一个groupId下面可能多个项目，就是靠artifactId来区分的;
<packaging>：打包的机制：如pom,jar, maven-plugin, ejb, war, ear, rar, par，默认为jar;
<version>：项目当前的版本号
<name>：另起一个项目名展示给用户
<description>：项目的详细描述, Maven 产生的文档用。
父项目标签
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.1.3.RELEASE</version>
<relativePath />
</parent>
<relativePath>：父项目的pom.xml文件的相对路径。相对路径允许你选择一个不同的路径。默认值是../pom.xml。Maven首先在构建当前项目的地方寻找父项目的pom，其次在文件系统的这个位置（relativePath位置），然后在本地仓库，最后在远程仓库寻找父项目的pom。
定义本项目的依赖关系 ：
<dependencyManagement>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope><optional>true</optional>
</dependency>
</dependencies>
</dependencyManagement>
继承自该项目的所有子项目的默认依赖信息。这部分的依赖信息不会被立即解析,它并不会被运行，就是不会营造实际的依赖，
主要用于父模块中定义供子模块使用,而当子项目声明一个依赖（必须描述group ID和artifact ID信息），如果group ID和artifact ID以外的一些信息没有描述，则通过group ID和artifact ID匹配到这里的依赖，并使用这里的依赖信息。
scope属性值：
- compile：编译期间，这是默认的范围，指的是依赖在编译的时候就需要存在，也会被打包进目标中
- provided：在编译和测试的时候有效，不打包到目标中，由工程使用或部署的环境提供该依赖
- runtime：在运行期间，通过maven compile命令编译的时候没有没关系，但是工程运行时，这个依赖必须存在
- test：测试期间，只会在测试代码编译和执行时需要
- system：系统指定，需要额外通过<systemPath>来指定依赖所在位置
- import：导入的依赖范围，它只使用在dependencyManagement中，表示从其它的pom中导入dependency的配置。
-
optional表示这个依赖是“可选的”，假设其他工程程引入本工程，那么这个可选依赖不会被带入，除非其他工程自己主动的引入了这个依赖。
2、pacakge、install和deploy的区别
（1）打包区别
- mvn package：打包到本项目，一般在项目target目录下。
- mvn install：打包到本地仓库，如果没设置Maven本地仓库，一般在用户/.m2目录下。
- mvn deploy：打包上传到远程仓库，如：私服nexus等，需要配置pom文件。
（2）打包过程
mvn clean package
依次执行：clean、resources、compile、testResources、testCompile、test、jar(打包)。
mvn clean install
依次执行：clean、resources、compile、testResources、testCompile、test、jar(打包)、install。
mvn clean deploy
依次执行：clean、resources、compile、testResources、testCompile、test、jar(打包)、install、deploy。
由上面分析主要区别如下：
- package命令：完成项目编译、单元测试、打包功能，但打包文件未部署到本地Maven仓库和远程Maven仓库。
- install命令：完成项目编译、单元测试、打包功能，同时把打包文件部署到本地Maven仓库，但未部署到远程Maven仓库。
- deploy命令：完成项目编译、单元测试、打包功能，同时把打包文件部署到本地Maven仓库和远程Maven仓库。
3、使用maven命令安装jar包到本地仓库
安装指定文件到本地仓库命令：mvn install:install-file -DgroupId=<groupId> : 设置上传到仓库的包名 -DartifactId=<artifactId> : 设置该包所属的模块名 -Dversion=1.0.0 : 设置该包的版本号 -Dpackaging=jar : 设置该包的类型(很显然jar包) -Dfile=<myfile.jar> : 设置该jar包文件所在的路径与文件名
eg：mvn install:install-file -DgroupId=com.zebra -DartifactId=ZSDK_API -Dversion=v2.12.3782 -Dpackaging=jar -Dfile=E:\perslib\ZSDK_API.jar
4、maven打包的几种方式
（1）无依赖其他任何的jar，在pom.xml中配置如下
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<classpathPrefix>lib/</classpathPrefix>
<mainClass>com.think.TestMain</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
</plugins>
</build> 执行mvn clean package，在target中找到打包出来的，命令后运行java -jar xxx.jar即可，但是如果程序有依赖其他包，比如程序依赖jdbc去查询db，这时候再执行就会出现找不到jdbc依赖，因为我们并没有将依赖包打进去。
（2）使用maven-assembly-plugin插件打包
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.3</version>
<configuration>
<appendAssemblyId>false</appendAssemblyId>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
<archive>
<manifest>
<mainClass>com.think.TestMain</mainClass>
</manifest>
</archive>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build> 其中<phase>package</phase>、<goal>single</goal>即表示在执行package打包时，执行assembly:single，所以可以直接使用mvn package打包。
(3)使用maven-shade-plugin插件打包
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.4.1</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<transformers>
<transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<mainClass>com.xxg.Main</mainClass>
</transformer>
</transformers>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build> 配置完成后，执行mvn package即可打包。在target目录下会生成两个jar包，注意不是original-xxx.jar文件，而是另外一个。和maven-assembly-plugin一样，生成的jar文件包含了所有依赖，所以可以直接运行。
如果项目中用到了Spring Framework，将依赖打到一个jar包中，运行时会出现读取XML schema文件出错。原因是Spring Framework的多个jar包中包含相同的文件spring.handlers和spring.schemas，如果生成一个jar包会互相覆盖。为了避免互相影响，可以使用AppendingTransformer来对文件内容追加合并：
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.4.1</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<transformers>
<transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<mainClass>com.xxg.Main</mainClass>
</transformer>
<transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
<resource>META-INF/spring.handlers</resource>
</transformer>
<transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
<resource>META-INF/spring.schemas</resource>
</transformer>
</transformers>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build> （4）SpringBoot的打包插件
很显然，这两个文件大小悬殊！为什么呢？
很明显，.original后缀和它的大小表明，这是“原始文件”，而.jar文件是一个FatJAR。在SpringBoot工程
中，这个31.1M大小的目标文件内部自带了一个“嵌入式Tomcat”，所以可以通过"java -jar"的命令直接启
动它。以此类推，如果<packaging>⽬标是WAR的话，也会得到2个文件：".war.original"和".war"，显
然需要使用“.war.original”文件，重命名后，将其部署到外部的Tomcat容器中。
（5）依赖传递与依赖冲突
依赖传递：简单来说，A依赖B，B依赖C，那么在A中是否会依赖C呢？
在所有的<scope>范围之中，compile、runtime、system会传递依赖关系。
依赖冲突：如果工程中对同样的<groupId>和<artifactId>引入了不同<version>的依赖，并且依赖关系都有效的话， 就 会发生依赖冲突。解决依赖冲突就是通过排除、换位等方式，指导只有一个<version>的依赖被使用即可。
关于分析多个<version>的依赖，哪个更有效的话，有一些原则可以参考：
路径最短优先原则
假设：A依赖1.0版本的C，B依赖2.0版本的C，此时如果A依赖B，那么此时A会中有2个C的依赖关系。但
是由于1.0版本是直接在A中依赖的，显然离A“更近，路径最短”，所以，对A来说，仍然是1.0版本的C是有
效依赖。
路径相同情况下，存在“覆盖”和“优先原则”
前者是说：在统一pom.xml中，可以使用位置靠后的依赖声明覆盖前面的依赖
后者是说：如果是2个pom.xml，那么使用最先的那个pom.xml中声明的依赖。比如A依赖B和C，但是B依
赖1.0版本的D，C依赖2.0版本的D，由于在A的pom.xml中，B的声明靠前，所以A会依赖1.0版本的D。
注意：显然靠上面的原则来解决冲突是不靠谱的，特别是在模块多、依赖关系很深的时候，根本搞不清楚
哪个是有效的依赖，此时需要使用“排除法”，主动排除不用的依赖。
扫一扫
581
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
