mapengpeng1999@163.com Maven

Maven

配置环境变量，本地仓库，阿里云镜像后，首次创建maven工程一定要联网下载相应的maven插件。
运行程序发现本地仓库没有相应的jar包，就会从阿里云镜像去下载相应的jar包。

Maven不是一门技术，是一个工具；Maven是一个项目架构管理工具；方便导入jar包，能根据需求自动下载所需jar包；

Maven是干什么的？
Maven是目前最流行的自动化构建工具，并不是作用于代码开发的任何一层，跟Git一样，对辅助编码没有作用。
在开发环境中，一个大的项目往往需要很多的工程，一个项目不仅仅是一个工程。
在这个时候，将多个工程整合在一起，那么就需要使用Maven这种自动化构建工具。读音：麦文。

Maven 是 Apache 软件基金会组织维护的一款自动化构建工具，专注服务于 Java 平台的项目构建和依赖管理。
Maven 这个单词的本意是：专家，内行。读音是['meɪv(ə)n]或['mevn]。

Maven是解决什么问题的

1.添加第三方 jar 包。
所有的项目中jar包都需要手动添加到项目中，存在很多相同的jar包重复的存放在很多的项目中，造成项目的体积庞大。

在今天的 JavaEE 开发领域，有大量的第三方框架和工具可以供我们使用。要使用这些 jar 包最简单
的方法就是复制粘贴到 WEB-INF/lib 目录下。但是这会导致每次创建一个新的工程就需要将 jar 包重复
复制到 lib 目录下，从而造成工作区中存在大量重复的文件，让我们的工程显得很臃肿。
而使用 Maven 后每个 jar 包本身只在本地仓库中保存一份，需要 jar 包的工程只需要以坐标的方式
简单的引用一下就可以了。不仅极大的节约了存储空间，让项目更轻巧，更避免了重复文件太多而造成的混乱。

2.jar 包之间的依赖关系。
jar包之间的依赖关系难以确认，很难正常的加入所有的jar包，maven能根据需求自动下载所需jar包。

jar 包往往不是孤立存在的，很多 jar 包都需要在其他 jar 包的支持下才能够正常工作，我们称之为
jar 包之间的依赖关系。最典型的例子是：commons-fileupload-1.3.jar 依赖于 commons-io-2.0.1.jar，
如果没有 IO 包，FileUpload 包就不能正常工作。
那么问题来了，你知道你所使用的所有 jar 包的依赖关系吗？当你拿到一个新的从未使用过的 jar包，
你如何得知他需要哪些 jar 包的支持呢？如果不了解这个情况，导入的 jar 包不够，那么现有的程
序将不能正常工作。再进一步，当你的项目中需要用到上百个 jar 包时，你还会手工的逐一确
认它们依赖的其他 jar 包吗？这简直是不可想象的。
而引入 Maven 后，Maven 就可以替我们自动的将当前 jar 包所依赖的其他所有 jar 包全部导入进来，
无需人工参与，节约了我们大量的时间和精力。用实际例子来说明就是：
通过 Maven 导入commons-fileupload-1.3.jar 后，commons-io-2.0.1.jar 会被自动导入，
程序员不必了解这个依赖关系。下图是 Spring 所需 jar 包的部分依赖关系

3.获取第三方 jar 包。  统一jar包规范。

JavaEE 开发中需要使用到的 jar 包种类繁多，几乎每个 jar 包在其本身的官网上的获取方式都不尽相同。
为了查找一个 jar 包找遍互联网，身心俱疲，没有经历过的人或许体会不到这种折磨。
不仅如此，费劲心血找的 jar 包里有的时候并没有你需要的那个类，又或者有同名的类没有你要的方法。
以不规范的方式获取的 jar 包也往往是不规范的。
使用 Maven 我们可以享受到一个完全统一规范的 jar 包管理体系。你只需要在你的项目中以坐标的
方式依赖一个 jar 包，Maven 就会自动从中央仓库进行下载，并同时下载这个 jar 包所依赖的其他 jar 包
——规范、完整、准确！一次性解决所有问题！
Tips：在这里我们顺便说一下，统一的规范几乎可以说成是程序员的最高信仰。如果没有统一的规范，
就意味着每个具体的技术都各自为政，需要以诸多不同的特殊的方式加入到项目中；
好不容易加入进来还会和其他技术格格不入，最终受苦的是我们。而任何一个领域的统一规范都能够极大的降低程序
员的工作难度，减少工作量。例如：USB 接口可以外接各种设备，如果每个设备都有自己独特的接口，
那么不仅制造商需要维护各个接口的设计方案，使用者也需要详细了解每个设备对应的接口，无疑是非常繁琐的。

4.将项目拆分成多个工程模块
我们现在的开发，一个项目就是一个工程，如果项目非常庞大，就不再适合使用package来划分模块，
最好的方式就是每个模块就是一个全新的工程，
对于我们工作的划分协调和代码维护来说，借助Maven就可以将一个项目拆分成多个工程。

随着 JavaEE 项目的规模越来越庞大，开发团队的规模也与日俱增。一个项目上千人的团队持续开
发很多年对于 JavaEE 项目来说再正常不过。那么我们想象一下：几百上千的人开发的项目是同一个 Web工程。
那么架构师、项目经理该如何划分项目的模块、如何分工呢？
这么大的项目已经不可能通过package 结构来划分模块，必须将项目拆分成多个工程协同开发。
多个模块工程中有的是Java工程，有的是Web工程。
那么工程拆分后又如何进行互相调用和访问呢？这就需要用到 Maven 的依赖管理机制。
上层模块依赖下层，所以下层模块中定义的 API 都可以为上层所调用和访问。

5.自动化构建。
一个正常的功能开发：编码---编译---打包---部署---测试，这5个环节，实际上真正需要人操作的就只有编码和测试，
其他的都是程式化的操作，现在的Eclipse可以帮我们进行自动编译，但是不能完成自动打包及自动部署。

什么是构建

Maven是一款专门服务于Java平台的自动化构建工具，目前自动化构建工具有很多：
- Maven
- Make
- Ant
- Grade
Maven并不是最新的，也不是最好用的，但是却是使用最为广泛的。

构建并不是创建，创建一个工程并不等于构建一个项目。要了解构建的含义我们应该由浅入深的从以下三个层面来看：

1.纯Java代码：我们都知道，Java是一门编译性语言，.java的扩展名的源文件需要编译成.class扩展名的字节码文件
才能够执行，所以编写任何 Java 代码想要执行的话就必须经过编译得到对应的.class 字节码文件。

2.Web工程：当我们需要通过浏览器访问 Java 程序时就必须将包含 Java 程序的 Web 工程编译的结果
“拿”到服务器上的指定目录下，并启动服务器才行。这个“拿”的过程我们叫部署。
我们可以将未编译的 Web 工程比喻为一只生的鸡，编译好的 Web 工程是一只煮熟的鸡，编译部署的过程就是将鸡炖熟。

3.实际项目：在在实际项目中整合第三方框架，Web 工程中除了 Java 程序和 JSP 页面、图片等静态资源之外，还包括第
三方框架的 jar 包以及各种各样的配置文件。所有这些资源都必须按照正确的目录结构部署到服务器上，项目才可以运行。

所以综上所述：
构建就是以我们编写的 Java 代码、框架配置文件、国际化等其他资源文件、JSP 页面和图片等静态资源作为“原材料”，
去“生产”出一个可以运行的项目的过程。

项目构建过程几个主要环节

1.清理：删除以前的编译结果，为重新编译做好准备。
2.编译：将 Java 源程序编译为字节码文件。
3.测试：针对项目中的关键点进行测试，确保项目在迭代开发过程中关键点的正确性。
4.报告：在每一次测试后以标准的格式记录和展示测试结果。
5.打包：将一个包含诸多文件的工程封装为一个压缩文件用于安装或部署。Java工程对应ja 包，Web工程对应war包。
6.安装：在 Maven 环境下特指将打包的结果——jar 包或 war 包安装到本地仓库中。
7.部署：将打包的结果部署到远程仓库或将 war 包部署到服务器上运行。

其实上述环节我们在 Eclipse 中都可以找到对应的操作，只是不太标准。
那么既然 IDE 已经可以进行构建了我们为什么还要使用 Maven 这样的构建工具呢？
Maven可以自动的从构建过程的起点一直执行到终点：清理，编译，测试，报告，打包，部署

Maven 的核心程序中仅仅定义了抽象的生命周期，而具体的操作则是由 Maven 的插件来完成的。
可是Maven 的插件并不包含在 Maven 的核心程序中，在首次使用时需要联网下载。
下载得到的插件会被保存到本地仓库中。本地仓库默认的位置是：~\.m2\repository。
具体操作参见“Maven 操作指南.txt”。

下载安装Maven

官网https://maven.apache.org

配置环境变量

1.先检查JAVA_HOME环境变量，一定要有java的JDK环境。

2.下载完成后，解压（解压到一个非中文无空格的目录下）。
如将apache-maven-3.2.2-bin.zip解压到一个非中文无空格的目录下。
例如：D:\MyApp\maven\apache-maven-3.6.3（类似tomcat配置，安装后可将压缩包删除）

3.在电脑的系统环境变量中，配置环境变量：
M2_HOME   D:\MyApp\maven\apache-maven-3.6.3		
Path  D:\MyApp\maven\apache-maven-3.6.3\bin （或者 %M2_HOME%\bin）

4.以管理员身份打开cmd敲命令，mvn -v，测试Maven是否安装成功，必须保证配置完毕。

约定的目录结构

约定的目录结构：一个完整的Maven工程需要按照Maven约定的结构来开发
		Hello
		|---src
		|---|---main
		|---|---|---java
		|---|---|---resources
		|---|---test
		|---|---|---java
		|---|---|---resources
		|---pom.xml

约定的目录结构对于 Maven 实现自动化构建而言是必不可少的一环，就拿自动编译来说，Maven 必须
能找到 Java 源文件，下一步才能编译，而编译之后也必须有一个准确的位置保持编译得到的字节码文件。
我们在开发中如果需要让第三方工具或框架知道我们自己创建的资源在哪，那么基本上就是两种方式：
①通过配置的形式明确告诉它
②基于第三方工具或框架的约定
Maven 对工程目录结构的要求就属于后面的一种。
现在 JavaEE 开发领域普遍认同一个观点：
约定>配置>编码。意思就是能用配置解决的问题就不编码，能基于约定的就不进行配置。
而 Maven 正是因为指定了特定文件保存的目录才能够对我们的 Java 工程进行自动化构建。

Maven中的核心概念

POM：Project Object Model，maven工程的核心配置文件就是pom.xml

pom.xml文件中的坐标（g,a,v）和依赖()

<?xml version="1.0" ?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>

	<groupId>com.wanbangee.maven</groupId>
	<artifactId>Hello</artifactId>
	<version>0.0.1-SNAPSHOT</version>

	<name>Hello</name> //当前项目中的模块名称，不写也行，和<artifactId>Hello</artifactId>一样
	  
	<dependencies>
		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>4.0</version>
			<scope>test</scope>
		</dependency>
	</dependencies>
</project>

坐标

几何中的坐标：
[1]在一个平面中使用 x、y 两个向量可以唯一的确定平面中的一个点。
[2]在空间中使用 x、y、z 三个向量可以唯一的确定空间中的一个点。
 
Maven 的坐标：
使用如下三个向量在 Maven 的仓库中唯一的确定一个Maven工程(可以确定Maven仓库中唯一的一个jar包)。
groupId：公司或组织域名倒序+当前项目名称，如<groupId>com.wanbangee.maven</groupId>
artifactId：当前项目中的模块名称，如<artifactId>Hello</artifactId>
version：当前模块的版本，如<version>0.0.1-SNAPSHOT</version>
 
如何通过坐标到仓库中查找 jar 包？
[1]将 gav 三个向量连起来
[2]以连起来的字符串作为目录结构到本地仓库repository中查找
注意：我们自己的 Maven 工程必须执行安装操作jar包才会进入仓库。安装的命令是：mvn install

依赖

- 依赖<dependency>：依赖是Maven中最关键的部分，Maven中最主要就是使用依赖来管理功能，依赖的目的是什么？
就是依赖jar包。当我们项目中需要使用一个A jar包，那么我们当前的项目就对A jar包产生了依赖，这是概念上的描述。
如何在项目中依赖一个jar包呢？


<!--依赖的所有jar包-->
	<dependencies>
		<!--依赖一个jar包-->
		<dependency>
			<!--通过jar包坐标的形式依赖这个jar包-->
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>4.0</version>
			<scope>test</scope>
		</dependency>
		
//要依赖另外JAR包就是找到其坐标，在网页百度maven repository，进入其官网搜索相应jar包，如Spring Core
		<dependency>
    		<groupId>org.springframework</groupId>
    		<artifactId>spring-core</artifactId>
    		<version>5.1.5.RELEASE</version>
		</dependency>
	</dependencies>

Maven库站

可以到 http://mvnrepository.com/搜索需要的 jar 包的依赖信息。

1.依赖的目的是什么

当 A jar 包用到了 B jar 包中的某些类时，A 就对 B 产生了依赖，这是概念上的描述。
那么如何在项目中以依赖的方式引入一个我们需要的 jar 包呢？
就是使用 dependency 标签指定被依赖 jar 包的坐标就可以了。

举例：在MakeFriend中依赖HelloFriend，在HelloFriend中依赖Hello
在HelloFriend中依赖Hello
<dependency>
			<groupId>com.wanbangee.maven</groupId>
			<artifactId>Hello</artifactId>
			<version>0.0.1-SNAPSHOT</version>
			<scope>compile</scope>
</dependency>
在MakeFriend中依赖HelloFriend
<dependency>
			<groupId>com.wanbangee.maven</groupId>
			<artifactId>HelloFriend</artifactId>
			<version>0.0.1-SNAPSHOT</version>
			<scope>compile</scope>
</dependency>

2.依赖的范围

大家注意到上面的依赖信息中除了目标 jar 包的坐标还有一个 scope 设置，这是依赖的范围。
一般使用<scope>compile</scope>
依赖的范围有几个可选值，我们用得到的是：compile、test、provided 三个。

从项目结构角度理解 compile 和 test 的区别:

结合具体例子：对于 HelloFriend 来说，Hello 就是服务于主程序的，junit 是服务于测试程序的。

HelloFriend 主程序需要 Hello 是非常明显的，测试程序由于要调用主程序所以也需要 Hello，
所以compile 范围依赖对主程序和测试程序都应该有效。
HelloFriend 的测试程序部分需要 junit 也是非常明显的，而主程序是不需要的，
所以 test 范围依赖仅仅对于测试程序有效。

从开发和运行这两个不同阶段理解 compile 和 provided 的区别：

- test ： test范围依赖的jar包只服务于测试程序
- compile ：compile范围依赖的jar包服务于主程序，也服务于测试程序
- provided ：provided 范围依赖的jar包服务于主程序，也服务于测试程序
那么对于compile范围和provided范围的依赖区别在哪里呢？
Compile和provided 范围的区别在于：
Compile是参与部署的依赖jar包，而provided 范围是不参与部署的依赖的jar包。


创建一个Maven的web工程来测试，依赖的有效性总结：
				Test		Compile		provided
主程序			 ×				√				√
测试程序		     √				√				√
参与部署		     ×				√				×

3.依赖的传递性

A依赖B，B依赖C，A 能否使用C呢？那要看B依赖C的范围是不是compile，
如果是compile则可用，否则不可用。

依赖的传递：在MakeFriends工程中没有依赖Hello这个jar包，却能够在MakeFriends中使用Hello jar包中的程序，这是为什么呢？如果依赖jar包的范围是compile，则这个jar包可以进行传递，
比如在A工程中依赖b.jar，b.jar中依赖c.jar,如果A工程工程中对b.jar的依赖是compile范围，b.jar中依赖的c.jar也是compile范围，则b.jar会将依赖的c.jar传递给A工程。

4.依赖的排除

如果我们在当前工程中引入了一个依赖是 A，而 A 又依赖了 B，那么 Maven 会自动将 A 依赖的 B 引入当前工程，
但是个别情况下 B 有可能是一个不稳定版，或对当前工程有不良影响。这时我们可以在引入 A 的时候将 B 排除。


依赖的排除：当我们当前工程中依赖了B jar包，而B jar包又依赖了C jar包，如果依赖的范围是compile范围，
这个时候C jar包就会被B jar包传递给当前工程，
如果说依赖自动传递的jar包 c是一个不稳定版本的jar包，或者对当前的工程会产生影响，
那么我们当前工程可以在依赖B jar包的时候将传递过来的C jar包排除。
<dependency>
			<groupId>com.wanbangee.maven</groupId>
			<artifactId>HelloFriend</artifactId>
			<version>0.0.1-SNAPSHOT</version>
			<type>jar</type>
			<scope>compile</scope>
			<!-- 依赖的排除，排除在HelloFriend中依赖Hello -->
			<exclusions>
				<exclusion>
					<groupId>com.wanbangee.maven</groupId>
					<artifactId>Hello</artifactId>
				</exclusion>
			</exclusions>
</dependency>

情景举例

配置方式

<dependency>
       <groupId>com.wanbangee.maven</groupId>
       <artifactId>HelloFriend</artifactId>
       <version>0.0.1-SNAPSHOT</version>
       <type>jar</type>
       <scope>compile</scope>
       <exclusions> 
             <exclusion> 
                   <groupId>commons-logging</groupId> 
                   <artifactId>commons-logging</artifactId> 
             </exclusion> 
       </exclusions> 
</dependency>

排除后的效果

5.统一管理所依赖 jar 包的版本

对同一个框架的一组 jar 包最好使用相同的版本。为了方便升级框架，可以将 jar 包的版本信息统一提取出来。

统一管理依赖的jar包版本：比如我们在开发SSM工程的时候，我们需要依赖很多的Spring的jar包，
那么这些Spring jar包如core ，beans，context，aop，excepress等等，肯定使用同一个版本的，这
个时候我们最好统一声明版本，这样有利于我们jar包的升级。
	<properties>
		<wanbang.spring.version>5.1.5.RELEASE</wanbang.spring.version>
	</properties>
	<dependencies>
		<dependency>
		    <groupId>org.springframework</groupId>
		    <artifactId>spring-core</artifactId>
		    <version>${wanbang.spring.version}</version>
		    <scope>compile</scope>
		</dependency>
		<dependency>
		    <groupId>org.springframework</groupId>
		    <artifactId>spring-beans</artifactId>
		    <version>${wanbang.spring.version}</version>
		    <scope>compile</scope>
		</dependency>
		<dependency>
		    <groupId>org.springframework</groupId>
		    <artifactId>spring-aop</artifactId>
		    <version>${wanbang.spring.version}</version>
		    <scope>compile</scope>
		</dependency>
	</dependencies>

统一声明版本号

<properties>
         <wanbangee.spring.version>4.1.1.RELEASE</atguigu.spring.version>
</properties>
其中 wanbangee.spring.version 部分是自定义标签。

引用前面声明的版本号

<dependencies>
    <dependency>
         <groupId>org.springframework</groupId>
         <artifactId>spring-core</artifactId>
          <version>${wanbangee.spring.version}</version>
    </dependency>
    ……
</dependencies>

其他用法

<properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

6.依赖的原则：解决 jar 包冲突

5.依赖的原则：jar包冲突解决原则，在MakeFriends中依赖了HelloFriend，HelloFriend中依赖了Hello，
并且将依赖的Hello传递给了MakeFriends，
现在在MakeFriends中直接依赖Hello，这个时候有两个Hello，造成了冲突，那么MakeFriends中使用哪个Hello呢？

路径最短者优先（就近原则）：

路径相同时，先声明者优先：

这里“声明”的先后顺序指的是 dependency 标签配置的先后顺序。

Maven仓库

Maven仓库的分类有：
- 本地仓库：为当前本机电脑上的所有 Maven 工程服务（不需要每次都去网上下载jar包）。
- 远程仓库：
- 本地私服：架设在当前的局域网环境下，为当前局域网内所有的maven工程服务
- 中央仓库：架设在Internet上，为全世界所有的maven工程服务
- 中央仓库的镜像：架设在各个大洲，为中央仓库分担流量。减轻中央仓库的压力，同时更快的响应用户请求。

Maven仓库中的文件：
- 第三方框架或工具的jar包
- Maven的插件
- 我们自己开发的功能模块安装的jar包
不管是什么样的jar包，在仓库中都是按照坐标(gav)生成目录结构的，所以可以通过统一的方式去查询依赖的jar包。

本地仓库配置

 <!-- localRepository
   | The path to the local repository maven will use to store artifacts.
   |
   | Default: ${user.home}/.m2/repository
  <localRepository>/path/to/local/repo</localRepository>
  -->
<localRepository>D:\MyApp\maven\apache-maven-3.6.3\repository</localRepository>

修改maven本地仓库的默认位置：默认情况下，本地仓库的位置是在家目录中
（默认本地仓库位置：C:\Users\teacher\.m2\repository）
如果电脑没有配置maven本地仓库，系统默认在C盘创建个本地仓库/.m2/repository（注意勾上文件隐藏目录）

建议：在maven解压后的目录中建个目录命名为repository，当作本地仓库
（repository就是将提前准备好的各种jar包库压缩包repository.rar解压）

在D:\MyApp\maven\apache-maven-3.6.3\conf中的settins.xml中配置本地仓库，记住不要加在注释中了。
在<localRepository>/path/to/local/repo</localRepository>
的后面加上这行代码
<localRepository>D:\MyApp\maven\apache-maven-3.6.3\repository</localRepository>

阿里云镜像

镜像：mirrors
作用：加速jar包下载（一般从国外的中央仓库下载很慢，用了阿里云镜像就下载快）
国内建议使用阿里云镜像，镜像可以配置多个，但一般配置一个就够用了。

修改下载jar包的远程仓库位置【中央仓库，中央仓库镜像，局域网私服】
修改连接远程仓库的位置，默认到maven的中央仓库下载，但是中央仓库下载速度慢，用阿里云这个mirror私服下载快。
一定要联网，发现本地仓库没有jar包会从网上去下载。

<mirrors>
    <!-- mirror
     | Specifies a repository mirror site to use instead of a given repository. The repository that
     | this mirror serves has an ID that matches the mirrorOf element of this mirror. IDs are used
     | for inheritance and direct lookup purposes, and must be unique across the set of mirrors.
     |
    <mirror>
      <id>mirrorId</id>
      <mirrorOf>repositoryId</mirrorOf>
      <name>Human Readable Name for this Mirror.</name>
      <url>http://my.repository.com/repo/path</url>
    </mirror>
     -->
	<mirror>
		<id>nexus-aliyun</id>
		<mirrorOf>central</mirrorOf>
		<name>Nexus aliyun</name>
		<url>http://maven.aliyun.com/nexus/content/groups/public</url>
	</mirror>
  </mirrors>

在D:\MyApp\maven\apache-maven-3.6.3\conf中的settins.xml中配置镜像，
在镜像<mirrors>  </mirrors>中放入阿里云镜像代码。

建议：自己去百度阿里云镜像，记住阿里云镜像代码不要用错，
否则会报错http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException

像下面的阿里云镜像代码是有问题的会报错。
    <mirror>
      <id>alimaven</id>
      <name>aliyun maven</name>
      <url>http://maven.aliyun.com/nexus/content/groups/public</url>
      <mirrorOf>central</mirrorOf>        
  	 </mirror>
  	 
使用maven打包报错如下：
[ERROR] Plugin org.springframework.boot:spring-boot-maven-plugin:1.5.4.RELEASE or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.springframework.boot:spring-boot-maven-plugin:jar:1.5.4.RELEASE: Could not transfer artifact org.springframework.boot:spring-boot-maven-plugin:pom:1.5.4.RELEASE from/to central (https://repo.maven.apache.org/maven2): Connect to repo.maven.apache.org:443 [repo.maven.apache.org/151.101.196.215] failed: Connection timed out: connect -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException

HelloWorld程序

先手动创建Maven工程，后期再使用Eclipse创建Maven工程。

①目录结构
		Hello
		|---src
		|---|---main
		|---|---|---java
		|---|---|---resources
		|---|---test
		|---|---|---java
		|---|---|---resources
		|---pom.xml

②POM文件内容
<?xml version="1.0" ?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>

	<groupId>com.wanbangee.maven</groupId>
	<artifactId>Hello</artifactId>
	<version>0.0.1-SNAPSHOT</version>

	<name>Hello</name>
	  
	<dependencies>
		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>4.0</version>
			<scope>test</scope>
		</dependency>
	</dependencies>
</project>

③编写主程序代码
		在src/main/java/com/wanbangee/maven目录下新建文件Hello.java，内容如下
		package com.wanbangee.maven;
		public class Hello {
			public String sayHello(String name){
				return "Hello "+name+"!";
			}
		}
		
④编写测试代码(JUnit测试)
		在/src/test/java/com/wanbangee/maven目录下新建测试文件HelloTest.java
		package com.wanbangee.maven;	
		import org.junit.Test;
		import static junit.framework.Assert.*;
		public class HelloTest {
			@Test
			public void testHello(){
				Hello hello = new Hello();
				String results = hello.sayHello("litingwei");
				assertEquals("Hello litingwei!",results);
				//断言，如果两个参数内容是一样的，测试就通过，不一样测试就报异常	
			}
		}
		
⑤运行几个基本的Maven命令
		D:换到D盘符
        cd D:\workspace(Spring tool suite)\Hello 进入到pom.xml目录

//执行任何命令都是从清理指令开始到命令结束
		mvn compile	编译	//pom.xml所在目录多了个target目录（存放编译后结果）
		mvn clean	清理  //pom.xml所在目录的traget消失了
		mvn test	测试  //traget又回来了
		mvn package	打包  //traget中会出现相应jar包
        mvn install 安装	//在maven本地仓库repository中多了个相应jar包
		※注意：运行Maven命令时一定要进入pom.xml文件所在的目录，即在Hello目录下！

运行编译指令mvn compile后发现，BUILD SUCCESS后发现Hello目录下多了个target目录（存放编译后结果）
运行清理指令mvn clean后发现，BUILD SUCCESS后发现Hello目录下的target目录消失了
运行测试指令mvn test后发现，就会执行刚才程序中那个test中JUnit的测试方法testHello()，
BUILD SUCCESS后发现Hello目录下又多了个target目录（存放程序编译的结果）
运行打包指令mvn package后发现，在target目录中多了个jar包（Hello+版本号）
运行安装指令mvn package后发现，在maven本地仓库repository中多了个jar包（Hello+版本号）

生命周期，不管执行哪条指令，都会从起点清理指令开始，比如执行测试，是先清理后编译再测试。
mvn package打包指令在测试指令后面，清理，编译，测试，打包，每次执行指令都是从头开始。

Maven生命周期

Maven 生命周期定义了各个构建环节的执行顺序，有了这个清单，Maven 就可以自动化的执行构建命令了。

●Maven 有三套相互独立的生命周期，分别是：
    ①Clean Lifecycle 在进行真正的构建之前进行一些清理工作。
    ②Default Lifecycle 构建的核心部分，编译，测试，打包，安装，部署等等。
    ③Site Life  cycle 生成项目报告，站点，发布站点。
它们是相互独立的，你可以仅仅调用 clean 来清理工作目录，仅仅调用 site 来生成站点。
当然你也可以直接运行 mvn clean install site 运行所有这三套生命周期。
每套生命周期都由一组阶段(Phase)组成，我们平时在命令行输入的命令总会对应于一个特定的阶段。
比如，运行 mvn clean，这个 clean 是 Clean 生命周期的一个阶段。有 Clean 生命周期，也有 clean 阶段。

Clean 生命周期一共包含了三个阶段：
    ①pre-clean 执行一些需要在 clean 之前完成的工作
    ②clean 移除所有上一次构建生成的文件
    ③post-clean 执行一些需要在 clean 之后立刻完成的工作
    
Site 生命周期：
①pre-site 执行一些需要在生成站点文档之前完成的工作
②site 生成项目的站点文档
③post-site 执行一些需要在生成站点文档之后完成的工作，并且为部署做准备
④site-deploy 将生成的站点文档部署到特定的服务器上
这里经常用到的是 site 阶段和 site-deploy 阶段，用以生成和发布 Maven 站点，
这可是 Maven 相当强大的功能，Manager 比较喜欢，文档及统计数据自动生成，很好看。

生命周期和自动化构建：
Default 生命周期是 Maven 生命周期中最重要的一个，绝大部分工作都发生在这个生命周期中。
这里，只解释一些比较重要和常用的阶段：
validate
generate-sources
process-sources
generate-resources
process-resources 复制并处理资源文件，至目标目录，准备打包。
compile 编译项目的源代码。
process-classes
generate-test-sources
process-test-sources
generate-test-resources
process-test-resources 复制并处理资源文件，至目标测试目录。
test-compile 编译测试源代码。
process-test-classes
test 使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署。
prepare-package
package 接受编译好的代码，打包成可发布的格式，如 JAR。
pre-integration-test
integration-test
post-integration-test
verify
install 将包安装至本地仓库，以让其它项目依赖。
deploy 将最终的包复制到远程的仓库，以让其它开发人员与项目共享或部署到服务器上运行。

运行任何一个阶段的时候，它前面的所有阶段都会被运行，例如我们运行 mvn install 的时候，
代码会被编译，测试，打包。这就是 Maven 为什么能够自动执行构建过程的各个环节的原因。
此外，Maven 的插件机制是完全依赖 Maven 的生命周期的，因此理解生命周期至关重要。

插件和目标

●Maven 的核心仅仅定义了抽象的生命周期，具体的任务都是交由插件完成的。
●每个插件都能实现多个功能，每个功能就是一个插件目标。
●Maven 的生命周期与插件目标相互绑定，以完成某个具体的构建任务。
例如：compile 就是插件 maven-compiler-plugin 的一个目标；
pre-clean 是插件 maven-clean-plugin 的一个目标。

继承

为什么需要继承呢？由于非compile范围的依赖不能在依赖链中传递，所以需要每个工程单独配置非compile范围的依赖，
就比如我们junit依赖。如果现在各个工程的junit版本都需要是4.9，那么这个时候各个工程手动去修改无疑是不可取的，使用继承就可以将这样的依赖信息统一到父工程中进行统一管理。

1.创建父工程和创建一般的 Java 工程操作一致，唯一需要注意的是：打包方式处要设置为 pom。
new个maven project，打包方式为pom，父工程是没有jre的。

2.在父工程中管理依赖（配置jar包的依赖）
用 dependencyManagement 标签将dependencies 标签括起来。
<?xml version="1.0" ?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.wanbangee.maven</groupId>
  <artifactId>Parent</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <packaging>pom</packaging>
  <modules>
  	<module>Hello</module>
  </modules>
  
  <dependencyManagement>
  	<dependencies>
  		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>4.9</version>
			<scope>test</scope>
		</dependency>
  	</dependencies>
  </dependencyManagement>
</project>

3.在子工程中引用父工程。
<?xml version="1.0" ?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>
	
	<!-- <groupId>com.wanbangee.maven</groupId> -->
	<artifactId>Hello</artifactId>
	<!-- <version>0.0.1-SNAPSHOT</version> -->
<!-- 如果子工程的坐标groupId和version与父工程一致，则可以省略子工程坐标groupId和version声明 -->

<!-- 引用父工程的坐标 -->
	<parent>
		  <groupId>com.wanbangee.maven</groupId>
 		  <artifactId>Parent</artifactId>
  		  <version>0.0.1-SNAPSHOT</version>
  		<!-- 配置当前工程目录到父工程的pom.xml文件的相对路径 -->
  		  <relativePath>../Parent/pom.xml</relativePath>
	</parent>
	
<!-- 添加依赖的jar包，依赖的jar包版本由父工程负责统一声明版本 -->
	<dependencies>
		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
		</dependency>
	</dependencies> 
</project>

可以在当前maven父工程（new个maven project勾上create a simple project和use default workspace location,
下一步packaging选pom就创建好了父工程，父工程是没有jre的)
右击父工程，new个maven module（子工程）
（勾上create a simple project，module name名字就是为子工程命名，parent project就是父工程的名字，
下一步打jar包就是java工程，打war包就是WEB工程）

聚合（用的少）

为什么需要聚合？
将一个项目拆分成多个工程之后，需要手动逐个安装到仓库后依赖才能够生效，
修改源码后也需要逐个工程单独的进行maven的各项操作。
而使用了聚合之后就可以对聚合的所有的工程统一的执行maven指令，比如打包，安装。。。。一次性全部打包，安装等。

聚合的配置：
在总的聚合工程中使用 modules/module 标签组合，指定模块工程的相对路径即可
<modules> 
    <module>../Hello</module> 
    <module>../HelloFriend</module> 
    <module>../MakeFriends</module>
</modules>
注意点：需要在pom打包方式的工程中配置聚合，即在父工程中配置聚合。

在Eclipse中使用Maven

Eclipse中创建maven工程，new个maven project(创建动态WEB，右击项目，选择properties，选择Project Facets)

在Eclipse中设置maven插件。

在IDEA中使用Maven

创建一个MavenWeb项目

Maven的G A V表示；G：组ID，公司域名倒置；A：项目名；V：版本

勾上importing中Sources源码，引入源码包但会影响IDEA性能速度。

创建一个普通的Maven项目

不勾create from archetype，直接下一步

标记文件夹功能

还有下面这种标记文件夹功能

在IDEA中配置tomcat

要在IDEA全局配置文件中配置