maven学习

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>

<parent>：指明项目的父POM

<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的打包插件

默认情况下，通过IDEA创建的SpringBoot工程会自带一个build plugin插件：

 

 

在这个插件之下，我们通过package命令可以打包工程，得到2个目标文件：

 

 

 

很显然，这两个文件大小悬殊！为什么呢？
很明显，.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。

注意：显然靠上面的原则来解决冲突是不靠谱的，特别是在模块多、依赖关系很深的时候，根本搞不清楚
哪个是有效的依赖，此时需要使用“排除法”，主动排除不用的依赖。

 

通过<exclusions>和<exclusion>标签排除依赖中的传递依赖。