日常开发需要掌握的Maven知识
文章来自：https://www.jianshu.com/p/e224a6dc8f20和https://www.jianshu.com/p/20b39ab6a88c
Maven出现之前
jar包默认都是放到/lib目录下，而如果要新增一个jar包，就需要到处找相应的jar包，如果这个jar包又依赖其他jar包，就比较坑爹了，
网上很多都需要积分或者VIP。或者是如果新建一个项目，我们需要把之前的jar拷贝过去，总之，jar包管理很麻烦
直到Maven出现
上述的关于jar包的各种闹心的问题都能迎刃而解，而我们只需要关心功能和业务
Maven的功能有哪些
1、工程的创建、测试
2、依赖管理
3、仓库管理
4、自动化部署
。。。。
仓库
仓库就是一个位置，可以存储jar包、library jar、插件任何其他的工程指定的文件。
1、本地仓库
第一次运行maven命令在本地创建的一个文件夹，会把依赖的jar包放到本地仓库，避免每次构建都引用远程仓库的依赖文件
默认地址：${user.home}/.m2/repository目录下。要修改默认位置，只要在 settings.xml文件中定义另一个路径即可，例如：
<localRepository>/anotherDirectory/.m2/respository</localRepository>
2、远程仓库
Maven的远程仓库可以是任何其他类型的存储库，可通过各种协议，例如 file：//和 http：// 来访问。这些存储库可以是由第三方
提供的可供下载的远程仓库，
例如Maven 的中央仓库(central repository)：
repo.maven.apache.org/maven2
uk.maven.org/maven2
也可以是在公司内的FTP服务器或HTTP服务器上设置的内部存储库，用于在开发团队和发布之间共享私有的 artifacts。
中央仓库
Maven 的中央仓库是 Maven 社区维护的，里面包含了大量常用的库，我们可以直接引用，但是前提是我们的项目能够访问外网。
maven仓库地址：https://mvnrepository.com/
私有仓库
除了 Maven 的中央仓库外，还有一种就是私有仓库，本人公司使用的就是私有仓库，因为在内网使用。
Maven依赖查找jar包顺序：
本地仓库--->私有仓库--->配置的中央仓库--->报错。这中间只要在某一个仓库中找到了就会返回了，除非仓库中有更新的版本，或者是snapshot版本。
Maven远程仓库配置：
<profiles>
<profile>
<id>central</id>
<repositories>
<repository>
<id>Central</id>
<name>Central</name>
<url>http://repo.maven.apache.org/maven2/</url>
</repository>
</repositories>
</profile>
</profiles>
<activeProfiles>
<activeProfile>central</activeProfile>
</activeProfiles>
镜像
Mirror相当于代理，我们配置镜像一般为了网速考虑
可以在Maven中配置该镜像来替代中央仓库。在settings.xml中配置如下代码：
<mirrors> <mirror> <id>maven.net.cn</id> <mirrorOf>maven.net.cn</mirrorOf> <name>one of the central mirrors in china</name> <url>http://maven.net.cn/content/groups/public/</url> </mirror> </mirrors>
生命周期
Maven有三个内置的构建生命周期： default， clean 和 site。每个生命周期都由一系列的阶段所构成
阶段的执行是按顺序的，一个阶段执行完成之后才会执行下一个阶段。
比如我们执行了一个如下的指令：
mvn install
实际会执行 install 阶段之前的所有阶段，然后才会执行 install 阶段本身。
常用：
1、clean：有问题就清理
2、package：打成jar或war包，自动进行clean和compile
3、install：将本地jar上传到本地仓库
4、deploy：将jar包上传到私服
PS：当我们的项目是多模块的，我们在最顶层执行该指令时，Maven 会遍历每一个子模块，依次执行所有的阶段。
坐标
groupId：表示一个团体，可以是公司、组织等
artifactId：表示团体下的某个项目
version：表示某个项目的版本号
他们之间的关系是一对多的，即每个团体下可以有多个项目，每个项目可以有多个版本号，可以用下面这张图来表示：
Scope依赖范围
Maven生命周期存在编译、测试、运行的过程，例如Junit只用于测试，MySQL驱动在编译期用不到，只是在运行期才使用，编译期用到的是JDBC接口，Tomcat
的servlet-api只在编译器用到，而运行期间不需要提供，因为有些容器已经提供
scope：
1、compile：默认的scope，运行期间有效，需要打到jar包
2、provided：编译期有效，运行期不提供，不打到jar包
3、runtime：编译期不需要，运行期有效，需要打到jar包（接口和实现分离）
4、test：测试需要，不打到jar包
5、system：非本地仓库引用、存在系统的某个路径下的jar包（一般不使用）
依赖
Maven 核心特点之一是依赖管理。一旦我们开始处理多模块工程(包含数百个子模块或者子工程)的时候，模块间的依赖关系就变得非常复杂，
管理也变得很困难。针对此种情形，Maven 提供了一种高度控制的方法。
1、依赖传递
如果引入一个jar包，这个jar包又依赖另一个jar包，项目编译时，maven会把直接引用和间接引用的jar包都下载到本地仓库。但是依赖传递有时又很麻烦，
因为很可能会造成依赖的冲突。
2、依赖冲突
当同一个项目中由于不同的jar包依赖了相同的jar包，此时就会发生依赖冲突的情况，如下图所示：
当项目中依赖了a和c，而a和c都依赖了b，这时就造成了冲突。为了避免冲突的产生，Maven 使用了两种策略来解决冲突，分别是短路优先
和声明优先。
依赖冲突不是指引入多个不同version的相同jar包，这种冲突，只能手动解决
在IDEA中，可以在pom.xml中，右键Maven--->Show Dependency，直接通过Ctrl+O查找具体某个jar，在pom文件中是否存在多个依赖
原文对依赖冲突有很详细的解释，原文地址在文章最上面
2.1、短路优先
短路优先的意识是，从项目一直到最终依赖的jar的距离，哪个距离短就依赖哪个，距离长的将被忽略掉。例如下图所示：
声明优先
声明优先的意思是，通过jar包声明的顺序来决定使用哪个，最先声明的jar包总是被选中，后声明的jar包则会被忽略，如下图所示：
依赖排除
如果我们只想引用我们直接依赖的jar包，而不想把间接依赖的jar包也引入的话，那可以使用依赖排除的方式，将间接引用的jar包排除掉，
如下面的配置所示：
<exclusions>
<exclusion>
<groupId>excluded.groupId</groupId>
<artifactId>excluded-artifactId</artifactId>
</exclusion>
</exclusions>
引入依赖的最佳实践
我们再添加依赖的时候，可能在运行的时候才发现依赖冲突，而实际上可以提前就发现问题
加入一个新的依赖的时候，先通过mvn dependency:tree形成依赖树，查看是否存在传递依赖，传递依赖中是否和依赖树中版本行程冲突，这时候可以提前解决
解决方案：
1、要使用哪个版本，我们是清楚的，那么能不能不管如何依赖传递，都可以进行版本锁定呢？
使用<dependencyManagement> [这种主要用于子模块的版本一致性中]
2、在依赖传递中，能不能去掉我们不想依赖的？
使用<exclusions> [在实际中我们可以在IDEA中直接利用插件帮助我们生成]
3、既然是最近依赖策略，那么我们就直接使用显式依赖指定版本，那不就是最靠近项目的么？
使用<dependency>
依赖管理
聚合
将多个项目同时运行就称为聚合，如下就是一个多模块的项目：
<packaging>pom</packaging>
<modules>
<module>module-1</module>
<module>module-2</module>
<module>module-3</module>
</modules>
聚合的优势在于可以在一个地方编译多个pom文件。
PS：聚合时packaging必须要是pom
继承
跟java类的继承类似，Maven 的继承特性也会继承父pom中的依赖，假设我们定义了一个父pom：
<groupId>com.houyi</groupId> <artifactId>maven-parent</artifactId> <version>0.0.1-SNAPSHOT</version> <dependencyManagement> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>${junit.version}</version> <scope>test</scope> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>5.1.30</version> </dependency> </dependencies> </dependencyManagement>
然后在子pom中引入这个父pom：
<!-- 指定parent，说明是从哪个pom继承 -->
<parent>
<groupId>com.houyi</groupId>
<artifactId>maven-parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
<!-- 指定相对路径 -->
<relativePath>../maven-parent</relativePath>
</parent>
<!-- 只需要指明groupId + artifactId，就可以到父pom找到了，无需指明版本 -->
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
</dependency>
</dependencies>
使用dependencyManagement，可对依赖进行管理。子类只要不引用这个里面写的groupId + artifactId，则不会添加依赖，这样防止造成重复加了包：
如果不使用dependencyManagement，那么只要写了dependency，子pom中会全部添加到依赖中，而其中很多包可能都用不上。
插件
插件是 Maven 的核心，所有执行的操作都是基于插件来完成的。
为了让一个插件中可以实现众多的相类似的功能，Maven 为插件设定了目标，一个插件中有可能有多个目标。其实生命周期中的每个阶段都是
由插件的一个具体目标来执行的
例如可以用下面的方式配置一个插件：
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.2.1</version>
<!-- 配置执行 -->
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>jar-no-fork</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
配置目标 goal 的目的是：这样在执行 mvn package 的时候，就会自动执行 mvn source:jar-no-fork了，jar-no-fork这个目标是用来进行源码打包的。
除了可以在build元素中配置插件，当然也可以在parent项目中，用pluginManagement来配置，然后在子项目继承即可使用。
PS：
通过插件我们可以做很多事，比如通过mybatis-generator 我们可以生成很多DAO层的代码，再配合通用Mapper+lombok使用的话就可以使你的代码
非常简洁，绝对的生产力工具！
指令
下面列举一些常用的 maven 指令：
指令参数
上面列举的只是比较通用的命令，其实很多命令都可以携带参数以执行更精准的任务。
Maven命令可携带的参数类型如下：
-D 传入属性参数
比如命令：mvn package -Dmaven.test.skip=true
以-D开头，将 maven.test.skip 的值设为 true ,就是告诉maven打包的时候跳过单元测试。
-P 使用指定的Profile配置
比如项目开发需要有多个环境，一般为开发，测试，预发，正式4个环境，在pom.xml中的配置如下：
<profiles>
<profile>
<id>dev</id>
<properties>
<env>dev</env>
</properties>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
</profile>
<profile>
<id>qa</id>
<properties>
<env>qa</env>
</properties>
</profile>
<profile>
<id>pre</id>
<properties>
<env>pre</env>
</properties>
</profile>
<profile>
<id>prod</id>
<properties>
<env>prod</env>
</properties>
</profile>
</profiles>
...
<build>
<filters>
<filter>config/${env}.properties</filter>
</filters>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>
profiles定义了各个环境的变量id，filters中定义了变量配置文件的地址，其中地址中的环境变量就是上面profile中定义的值，resources中是定义
哪些目录下的文件会被配置文件中定义的变量替换。
通过maven可以实现按不同环境进行打包部署，命令为:
mvn package -P dev
其中 dev 为环境的变量id,代表使用Id为 dev 的 profile。
-e 显示maven运行出错的信息
-o 离线执行命令,即不去远程仓库更新包
-X 显示maven允许的debug信息
-U 强制去远程更新snapshot的插件或依赖，默认每天只更新一次
举个例子
将自己的jar包部署到远程仓库去，可以使用 deploy 指令：
mvn deploy:deploy-file -DgroupId=<group-id> \ -DartifactId=<artifact-id> \ -Dversion=<version> \ -Dpackaging=<type-of-packaging> \ -Dfile=<path-to-file> \ -DrepositoryId=<id-to-map-on-server-section-of-settings.xml> \ -Durl=<url-of-the-repository-to-deploy>
最后说下我们为什么要学习maven，大概可以收获这些好处吧：
- 提高自己的生产力
- 更好的管理项目中的jar包
- 自己开发的jar包可以共享给别人
- 遇到jar包冲突问题可以不求人
。。。
