Maven学习笔记（下）
Maven学习笔记（下）
上篇我们介绍了Maven的基本原理等等，这一篇本文将开始以idea搭建Maven项目为主。
1、IDEA搭建Maven项目
1.1 IDEA集成Maven插件
通过入门程序中命令行的方式使用Maven工作效率不高，可以在开发工具中集成Maven软件，idea是一个开发工具，Maven是一个项目管理工具，Maven有一套项目构建的规范，在idea集成Maven软件，最终通过idea创建Maven工程。
1.打开idea后，进入主界面点击configure后点击settings
2.可以在快捷查找框输入Maven查找与Maven相关配置然后点击Maven，在如下选框中填入相关信息。
注意：这里的文件尽量是自己下载一步一步配置的。小编在检查后发现自己User settings files还是用的其他的settings文件。
3.点击Runner，填写JRE。
1.2 定义Maven坐标
每个Maven工程都需要定义本工程的坐标，坐标是Maven对jar包的身份定义。
<groupId>com.jpggroupId>
<artifactId>my-first-MavenartifactId>
<version>0.0.1-SNAPSHOTversion>
<packaging >jarpackaging>
这是小编在创建Maven项目前准备的Maven坐标。
1.3 创建Maven的Java工程
在在这里创建Maven工程分两种情况，在这里为了先了解我这里选择使用骨架创建，后续会带来无骨架创建。
1.先创建项目，选择中左侧的Maven并将Create from archetype选中，在下方选择的是骨架quickstart。点击Next。
注意：上面选择自己安装的jdk版本。
2.填写项目时，请填写项目的名称以及存储位置。点击Artifact Coordinates，填写项目坐标的基本信息。
这里根据前面自己设定的坐标填写GroupId，项目名根据自己创建即可，这里使用的是demo01。
3.后续的检查机会不要错过，像这次检查我才发现自己前面发现的问题。检查也至关重要！！！
4.最后生成目录
如果是开始入手的Maven的朋友看到一开始只有idea目录不要紧张，idea会帮大家下载Maven所相关的包，稍等片刻即可完成。如下所示：
当然，后续还需要自己手动创建resources补齐文件夹目录。首先在main下创建文件夹并展示创建后的目录结构。
后续的test也要创建resources，跟前面的步骤一样。
以上是有骨架创建java工程的流程。
1.4 创建Maven的Java web工程
1.同如上一样，将Create from archetype选中，在下方选择骨架webapp，点击Next。
2.坐标填写+检查一样不能少
3.创建好初始的目录后，还需要自己补齐一些目录
补充前：
补充后：
1.5 构建完整的Web项目
首先咱们将刚刚创建的web项目中编写一个jsp页面和servlet，然后可以通过配置的tomcat插件方式运行项目。
在pom.xml文件添加如下的内容：
<packaging>warpackaging>
<dependencies>
<dependency>
<groupId>javax.servletgroupId>
<artifactId>javax.servlet-apiartifactId>
<version>4.0.1version>
<scope>providedscope>
dependency>
<dependency>
<groupId>javax.servlet.jspgroupId>
<artifactId>jsp-apiartifactId>
<version>2.0version>
<scope>providedscope>
dependency>
dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.tomcat.mavengroupId>
<artifactId>tomcat7-maven-pluginartifactId>
<version>2.2version>
<configuration>
<port>80port>
<path>/linapath>
configuration>
plugin>
plugins>
build>
注意：标签要加上，不然加载资源会发生冲突会抛出异常。
servlet大家可以自行编写，后续jsp随便编写尝试一下。
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
Title
hello world
配置tomcat插件并点击按钮即可。
最后得到如下结果。
2、Maven常用指令
Maven的命令需要在pom.xml所在目录中执行以下命令。
2.1 mvn compile
执行mvn compile命令来完成编译操作.。
执行完毕后，会生成target目录，该目录中存放了编译后的字节码文件。
接下来以上文demo2为实例尝试在cmd操作Maven。
Win+R输入CMD后cd到当前项目。比如我的项目目录在C:\Users\86188\IdeaProjects\demo02。
输入mvn compile后出现如下结果
2.2 mvn clean
执行mvn clean命令,执行完毕后，会将target目录删除。
2.3 mvn test
执行mvn test命令时，完成单元测试操作。执行完毕后，会在target目录中生成三个文件夹：surefile、surefire-reports（测试报告）、test-classes（测试的字节码文件）。
2.4 Maven package
执行mvn package命令后，完成打包工作。
执行完毕后，会在target目录下生成一个文件，该文件可能是jar、war。
2.5 mvn install
执行mvn install命令，完成将打好的jar包安装到本地仓库的操作。
执行完毕后，会在本地仓库中出现安装后的jar包，方便其他工程引用。
2.6 mvn clean compile 命令
cmd 中录入 mvn clean compile 命令
组合指令，先执行clean，再执行compile，通常应用于上线前执行，清除测试类
2.7 mvn clean test 命令
cmd 中录入 mvn clean test 命令
组合指令，先执行clean，再执行test，通常应用于测试环节 。
2.8 mvn clean package 命令
cmd 中录入 mvn clean package命令
组合指令，先执行clean，再执行package，将项目打包，通常应用于发布前。
执行过程：
清理————清空环境
编译————编译源码
测试————测试源码
打包————将编译的非测试类打包
2.9 mvn clean install 命令
cmd 中录入 mvn clean install 查看仓库，当前项目被发布到仓库中。
组合指令，先执行clean，再执行install，将项目打包，通常应用于发布前。
部署————将打好的包发布到资源仓库中
3、Maven的传递性和依赖性
3.1 依赖管理
对项目中的jar包管理，可以在pom文件中定义Jar包的GAV坐标，管理依赖。
依赖声明主要包含如下元素：
<dependencies>
<dependency>
<groupId>junitgroupId>
<artifactId>junitartifactId>
<version>4.10version>
<scope>testscope>
dependency>
dependencies>
其中的原理用图片说明：
3.2 依赖范围（scope取值）
对于不同的jar包，对应不同的依赖范围。
3.2.1 compile-默认值
在编译范围中，默认，在工程环境中的classpath和打包（如果是WAR包，就会在WAR包中生效）时都有效。
3.2.2 provided
容器或者JDK已提供的范围内，表示该依赖包已经由目标容器和JDK提供，只有在编译的classpath中加载和使用，打包的时候不回包含在目标的包中。
比如对于servlet-api而言就是由servlet容器提供，无需打包到war包中。否则不配置成provided时，在tomcat的一定版本会出现冲突而无法正常运行程序。
3.2.3 runtime
runtime一般用于运行和测试环境使用，编译时候不用加入classpath，打包时候会打包到目标包中。一般是通过动态加载或接口反射加载的情况比较多。
也就是说程序只使用了接口，具体的时候可能有多个，运行时通过配置文件或jar包扫描动态加载的情况。典型的包括：JDBC驱动等。
3.2.4 test
测试范围内一般使用的时单元测试场景使用。在编译环境时加入classpath，但打包时不会加入，比如说junit等。
在网上查的时候，我发现其实还有system，但是很少人会使用这个标签取值。这是因为它不利于项目的合作开发，不同的机器可能不会兼容。
3.3 依赖传递
这跟SQL的依赖关系很相似。比如说B中使用A，C中使用B，我们可以称：B是C的直接依赖，而称A是C的间接依赖。
C->B
B->A
C直接依赖B
C间接依赖A
3.3.1 依赖的范围对依赖传递的最终影响
如上图所示，左边第一列表示第一直接依赖范围，上面第一行表示第二直接依赖范围，中间的交叉单元格表示传递性依赖范围。
总结如下：
(1) 当第二依赖的范围是compile的时候，传递性依赖的范围与第一直接依赖的范围一致。
(2) 当第二直接依赖的范围是test的时候，依赖不会得以传递。
(3) 当第二依赖的范围是provided的时候，只传递第一直接依赖范围也为provided的依赖，且传递性依赖的范围同样为 provided；
(4) 当第二直接依赖的范围是runtime的时候，传递性依赖的范围与第一直接依赖的范围一致，但compile例外，此时传递的依赖范围为runtime；
3.3.2 依赖冲突
- 如果直接与间接依赖中包含有同一个坐标不同版本的资源依赖，以直接依赖的版本为准（就近原则）
- 如果直接依赖中包含有同一个坐标不同版本的资源依赖，以配置顺序下方的版本为准（就近原则）
3.3.3 可选依赖
可选依赖 true/false 用于设置是否可选，也可以理解为jar包是否向下传递。
在依赖中添加optional选项决定此依赖是否向下传递，如果是true则不传递，如果是false就传递，默认情况为false。
3.3.4 排除依赖
Maven的传递依赖能自动将间接依赖引入项目中来，这样极大地简化了项目中的依赖管理。但是有时候，间接依赖的关联包可以因为版本或其他原因，并不是我们想要的版本。
这种做法就是排除依赖。我们可以在直接依赖的配置里面添加exclusions→exclusion 元素，指定要排除依赖的groupId 和 artifactId 就行。如下面代码所示。
<dependency>
<groupId>junitgroupId>
<artifactId>junitartifactId>
<version>4.11version>
<scope>testscope>
<exclusions>
<exclusion>
<groupId>org.hamcrestgroupId>
<artifactId>hamcrest-coreartifactId>
exclusion>
exclusions>
dependency>
这里排除依赖时并不需要添加依赖包的版本号。
4、Maven插件
Maven的核心仅仅定义了抽象的生命周期，具体的任务都是交由插件完成的。每个插件能实现一个功能，而功能的实现就是一个插件目标。Maven的生命周期与插件目标相互绑定，以完成某个具体的构建任务。
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.pluginsgroupId>
<artifactId>maven-compiler-pluginartifactId>
<version>3.8.0version>
<configuration>
<source>1.8source>
<target>1.8target>
configuration>
plugin>
plugins>
build>
我们之前创建的web项目都需要额外配置tomcat以后才能运行项目，现在Maven提供了tomcat插件， 这样我们就无需再添加额外的tomcat了。
步骤1:创建Maven类型的web工程
步骤2: pom.xml文件中添加插件信息
<plugins>
<plugin>
<groupId>org.apache.tomcat.mavengroupId>
<artifactId>tomcat7-maven-pluginartifactId>
<version>2.2version>
<configuration>
<port>8080port>
<path>/path>
configuration>
plugin>
plugins>
步骤3:像idea配置configuratiion即可。
5、Maven私服
比如说项目组编写了一个通用的工具类用来获取阿里云的短信服务，而其它项目组将类拷贝过去使用。当工具类修改bug后通过随机的通讯手段发送给各个项目组，这种分发机制的不规范可能会导致工具类版本不一致。
根据如上所说，我们可以使用Maven创建打成jar包，将jar包发布到公司的Maven仓库中。而公司的仓库简称私服。其他项目通过Maven依赖管理从仓库自动下载jar包。
私服作用：
1、将自己的工程打包jar发布到私服。
2、从私服下载jar包到自己的工程中。
通过以上介绍，我们简单的讲述了Maven的依赖管理，在idea配置和常用指令的介绍。谢谢大家收看。