一、Maven->conf->settings.xml文件配置
E:\szsgg\video\4maven\apache-maven-3.5.4\conf\setting配置
1. 配置本地仓库
<localRepository>E:\szsgg\video\4maven\repo</localRepository>
2. 配置下载网站地址
<mirrors>
<mirror>
<id>nexus-aliyun</id>
<mirrorOf>central</mirrorOf>
<name>Nexus aliyun</name>
<url>http://maven.aliyun.com/nexus/content/groups/public</url>
</mirror>
</mirrors>
3. 配置JDK环境
<profiles>
<profile>
<id>jdk-1.8</id>
<activation>
<activeByDefault>true</activeByDefault>
<jdk>1.8</jdk>
</activation>
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<maven.compiler.compilerVersion>1.8</maven.compiler.compilerVersion>
</properties>
</profile>
</profiles>
二、idea创建maven工程
- 创建空工程
File->new->project->Empty project
- 空工程中创建maven模块
New->module->创建，需要特别注意标红地方，父工程选none,工程路径确保在工程下而不是模块下
三、Maven工程中易出现的问题？
1. 在一个模块调用另一个模块进行test报错？
有可能是配置文件没有进行导入依赖，先查看是否导入
可能是模块的jar包没有放到仓库中，需要将模块jar包放置本地仓库
步骤： 找到此工程->选择install命令放置到仓库再次运行即可
2. 依赖范围可见性问题
compile（默认就是这个范围）
（1）main目录下的Java代码可以访问这个范围的依赖
（2）test目录下的Java代码可以访问这个范围的依赖
（3）部署到Tomcat服务器上运行时要放在WEB-INF的lib目录下
例如：对Hello的依赖。主程序、测试程序和服务器运行时都需要用到。
2）test
（1）main目录下的Java代码不能访问这个范围的依赖
（2）test目录下的Java代码可以访问这个范围的依赖
（3）部署到Tomcat服务器上运行时不会放在WEB-INF的lib目录下
例如：对junit的依赖。仅仅是测试程序部分需要。
3）provided
（1）main目录下的Java代码可以访问这个范围的依赖
（2）test目录下的Java代码可以访问这个范围的依赖
（3）部署到Tomcat服务器上运行时不会放在WEB-INF的lib目录下
3. 依赖的间接传递性
当存在间接依赖的情况时，主工程对间接依赖的jar可以访问吗？这要看间接依赖的jar包引入时的依赖范围——只有依赖范围为compile时可以访问。例如：
Maven工程 | 依赖范围 | 对A的可见性 | ||
A | B | C | compile | √ |
D | test | × | ||
E | provided | × | ||
4. 如何解决依赖间的冲突问题？
1.路径最短者优先，当本工程依赖或间接依赖两个不同的版本时，采用离本工程最近的工程
2.路径相同时先声明者优先
这里“声明”的先后顺序指的是dependency标签配置的先后顺序，也就是本工程依赖写在xml文件中最前面的jar包
5. 如何将依赖中不需要的jar包去掉？也叫依赖的排除
在pro.xml中找到所导入的依赖，添加以下代码，切记需要添加到dependency标签下
<exclusions>
<exclusion>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</exclusion>
</exclusions>
6. 自定义标签（解决依赖过多时修改版本号一事）
以对Spring的jar包依赖为例：Spring的每一个版本中都包含spring-context，springmvc等jar包。我们应该导入版本一致的Spring jar包，而不是使用4.0.0的spring-context的同时使用4.1.1的springmvc。
但是如果我们一个一个修改，就会很麻烦。所以我们可以自定义一个标签进行统一管理依赖的版本号，类似于java中的变量赋值，当需要修改时就可以统一修改，此标签需要写在pro.xml的最上面
<!--统一管理当前模块的jar包的版本-->
<properties>
<spring.version>4.0.0.RELEASE</spring.version>
</properties>
7. 生命周期
什么是Maven的生命周期？
Maven生命周期定义了各个构建环节的执行顺序，有了这个清单，Maven就可以自动化的执行构建命令了。
Maven有三套相互独立的生命周期，分别是：
- Clean Lifecycle在进行真正的构建之前进行一些清理工作。
- Default Lifecycle构建的核心部分，编译，测试，打包，安装，部署等等。
- Site Lifecycle生成项目报告，站点，发布站点。
再次强调一下它们是相互独立的，你可以仅仅调用clean来清理工作目录，仅仅调用site来生成站点。当然你也可以直接运行mvn clean install site运行所有这三套生命周期。
每套生命周期都由一组阶段（Phase）组成，我们平时在命令行输入的命令总会对应于一个特定的阶段。比如，运行mvn clean，这个clean是Clean生命周期的一个阶段。有Clean生命周期，也有clean阶段。
生命周期与自动化构建
运行任何一个阶段的时候，它前面的所有阶段都会被运行，例如我们运行mvn install 的时候，代码会被编译，测试，打包。这就是Maven为什么能够自动执行构建过程的各个环节的原因。此外，Maven的插件机制是完全依赖Maven的生命周期的，因此理解生命周期至关重要。
四、继承
使用继承机制就可以将这样的依赖信息统一提取到父工程模块中进行统一管理。
1.创建父工程
（1）父工程的打包方式为pom
<groupId>com.atguigu.maven</groupId>
<artifactId>Parent</artifactId>
<packaging>pom</packaging>
<version>1.0-SNAPSHOT</version>
（2）父工程只需要保留pom.xml文件即可。
2.在子工程中引用父工程
（1）父工程坐标
<parent>
<!-- 父工程坐标 -->
<groupId>...</groupId>
<artifactId>...</artifactId>
<version>...</version>
<!--指定从当前pom.xml文件出发寻找父工程的pom.xml文件的相对路径-->
<relativePath>..</relativePath>
</parent>
（2）继承
<!--继承-->
<parent>
<groupId>com.atguigu.maven</groupId>
<artifactId>Parent</artifactId>
<version>1.0-SNAPSHOT</version>
<!--指定从当前pom.xml文件出发寻找父工程的pom.xml文件的相对路径-->
<relativePath>../Parent/pom.xml</relativePath>
</parent>
此时如果子工程的groupId和version如果和父工程重复则可以删除
3. 在父工程中管理依赖
（1）将Parent项目中的dependencies标签，用dependencyManagement标签括起来。
<!--依赖管理-->
<dependencyManagement>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.0</version>
<scope>test</scope>
</dependency>
</dependencies>
</dependencyManagement>
（2）在子项目中重新指定需要的依赖，删除范围和版本号。
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</dependency>
五、酷站
我们可以到http://mvnrepository.com/搜索需要的jar包的依赖信息。
