Maven的安装\配置以及使用
Maven 的主要目标是让开发人员在最短的时间内了解开发工作的所有状态。为了实现这一目标，马文涉及几个令人关切的领域：
使构建过程变得简单
提供统一的构建系统
提供高质量的项目信息
鼓励更好的发展做法
去官网下载适合的maven
这里用到的是3.8.3版本;
下载之后解压,将文件放到一个合适的目录,我是放在了
之后开始配置maven,maven跟java一样,都需要有一个path的环境变量----
注意---->>在配置maven之前一定要配置好java环境变量;
检查一下java环境变量----->>>
在配置maven时,你可以可建一个MAVEN_HOME, path中引用MAVEN_HOME的方式也可以
配置 maven的 环境变量
在path环境变量下添加maven配置,目标位maven的bin目录
配置完之后检查配配置是否成功-----
在控制输入 mvn -v,如果有反应,说明配置成功
虽然配置成功了,但是由于是第一次配置,还需要一些其他依赖文件,在控制台输入–
mvn archetype:generate -DgroupId= -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4 -DinteractiveMode=false
注意,这会在你本地用户文件夹下创建一个maven项目,找起来比较麻烦,所以建议自己指定一个文件夹来存放maven项目,
你也可以模仿我这么操做----
控制台进入D:\Program Files\mavenProjects文件夹,然后执行上方命令
这个操做会从官网下载一些依赖以及一些配置文件,执行成功会有 BUILD SUCCESS提示;
同时检查
maven项目目录----->>>
出现my-app说明操做成功,至此maven安装与配置就结束了;
生成目标创建了my-app名称目录。。
cd my-app
根据此目录，您将注意到以下标准项目结构。
my-app
|-- pom.xml-- src |-- main |– java
| -- com |– mycompany
| -- app |– App.java-- test– java-- com– mycompany-- app– AppTest.java
目录包含项目源代码，目录包含测试源，文件是项目的项目对象模型（POM）
最后说一下如何让卸载maven,由于不是直接安装的maven,所以
卸载起来很简单------>>
1,环境变量中删除maven配置,
2,删除maven所在文件
3清理maven仓库-----即项目存放的地方
maven中一些常用的命令
构建项目
mvn package
这需要在pom.xml所在文件夹下执行,要不然会提示找不到pom.xml文件错误;
打包好之后控制台会提示----
这是我们打包好的jar文件位置所在D:\mavenProjects\my-app\target\my-app-1.0-SNAPSHOT.jar
用以下命令测试新编译和打包的 JAR：
java -cp target/my-app-1.0-SNAPSHOT.jar .App
mvn clean dependency:copy-dependencies package
此命令将清理项目、复制依赖项并打包项目（当然，执行所有阶段到包）。
生成站点
mvn site
maven的使用
要了解maven是什么,首先得分析一下我们传统写java项目的时候 ,我们经常会导入一些依赖包,比如jdbc驱动,jstl标签库,log4j等等,将他们放在classpath中,虽然这些工作难度不大,但是比较繁琐;
maven针对这个问题专门位java项目的开发提供了一套管理和构建工具;
提供了一套标准化的项目结构；
提供了一套标准化的构建流程（编译，测试，打包，发布……）；
提供了一套依赖管理机制。
Maven项目结构
一个使用Maven管理的普通的Java项目，它的目录结构默认如下：
a-maven-project —项目名
├── pom.xml – 项目描述文件
├── src —项目根目录
│ ├── main
│ │ ├── java —java源码存放处
│ │ └── resources —资源文件
│ └── test —测试项目的目录
│ ├── java—java源码存放处
│ └── resources —资源文件
└── target 编译,打包好的文件存放处
pom.xml文件分析
groupId类似于Java的包名，通常是公司或组织名称，artifactId类似于Java的类名，通常是项目名称，再加上version，一个Maven工程就是由groupId，artifactId和version作为唯一标识。我们在引用其他第三方库的时候，也是通过这3个变量确定。
通过上述3个变量，即可唯一确定某个jar包。Maven通过对jar包进行PGP签名确保任何一个jar包一经发布就无法修改。修改已发布jar包的唯一方法是发布一个新版本。
因此，某个jar包一旦被Maven下载过，即可永久地安全缓存在本地。
以上是maven本地加载的一些核心包名
,如果要使用的包,那么需要配置依赖-----
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.2</version>
</dependency>
使用声明一个依赖后，Maven就会自动下载这个依赖包并把它放到classpath中。
那maven是从哪里下载我们需要的依赖包呢?
首先maven维护了一个仓库,基本上所有的依赖包都会上传到这个仓库,这个就不需要我们关心了;
那有一个小细节,我们怎么知道对应的 以及 呢?
我们可以通过maven仓库 来搜索关键字 搜索得到上面三个信息—
Maven Central Repository Search
从maven的官方仓库下载一些依赖包会比较慢,一般是使用ALIYUN的仓库替代官方仓库
使用Maven镜像仓库需要一个配置，在用户主目录下进入.m2目录，创建一个settings.xml配置文件，内容如下：
<settings>
<mirrors>
<mirror>
<id>aliyun</id>
<name>aliyun</name>
<mirrorOf>central</mirrorOf>
<!-- 国内推荐阿里云的Maven镜像 -->
<url>https://maven.aliyun.com/repository/central</url>
</mirror>
</mirrors>
</settings>
上述三个元素指向一个项目的特定版本，让 Maven 知道当在其软件生命周期中，我们正在处理哪个项目;
配置好后接下来就是maven的一些基础知识
包的依赖关系
在java中,maven解决的是有关包的依赖关系,
在maven中定义了几种依赖关系---->>>
complie 这说明编译时需要用到该jar包 例如 commons-logging
test 在测试环境下 需要用到该jar包 例如junit
runtime 编译时不需要,但是运行时需要用到 例如 jdbc驱动
provided 编译时需要用到,但运行时由某个JDK或者某个服务器提供 例如 某个servlet
complie
complie是最基本的也最常用 ,maven会将这种类型的依赖直接放入classpath,如果不声明则scope默认为complie
test
测试时会用到,打包时不会放到项目中,比如junit的jar包
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.11</version>
<scope>test</scope>
</dependency>
</dependencies>
runtime
运行时才会依赖的jar包,比如数据库连接
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>8.0.27</version>
<scope>runtime</scope>
</dependency>
provided
编译和测试项目的时候需要该依赖，但在运行项目的时候，由于容器已经提供，就不需要Maven重复地引入一遍(如：servlet-api)
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>4.0.0</version>
<scope>provided</scope>
</dependency>
system
一些本地包可以这么引入
<dependency>
<!--注册自定义jar包-->
<groupId>com.gavin.test</groupId>
<artifactId>Maven_gavin</artifactId>
<version>1.0-SNAPSHOT</version>
<scope>system</scope>
<systemPath>com.gavin.demo</systemPath><!--url -->
</dependency>
import
import范围只适用于pom文件中的部分。表明指定的POM必须使用部分的依赖。
注意：import只能用在dependencyManagement的scope里。
import用于中,主要用于对版本的管理
指定一个maven项目中的pom.xml为父类pom,
如果子类pom写上版本号,则会按照子类中的版本号走;
但是父类pom可以强制子类pom使用其指定的版本
maven会对开发版的项目中的一些依赖每次都会重新下载依赖,在maven中以SNAPSHOT结尾的版本号会被视为开发版本,这种SNAPSHOT版本只能用于内部私有的Maven repo，公开发布的版本不允许出现SNAPSHOT
在配置好maven环境时候,下载的资源中已经为我们准备好一个项目—myapp,我们可以通过这个来测试一下一些常用命令—
mvn -v ----查看maven版本以及JDK和系统版本
mvn package -----打包项目
java -cp target/my-app-1.0-SNAPSHOT.jar .App ---- 运行项目
运行项目的命令解析—
java -cp
target ----项目存放相对地址 ,也可以写项目绝对地址不过要把证地址准确性
my-app-1.0-SNAPSHOT.jar —jar包名
----包名即 pom.xml中配置的groupId
.POM 型号版本（始终为 4.0.0）。
.项目所属的团体或组织。通常表示为倒置域名。
.要给项目图书馆文物起的名字（例如，其 JAR 或 WAR 文件的名称）。
.正在构建的项目版本。
- 应如何包装项目。JAR 文件包装的默认"jar"。使用"war"进行war文件包装。
实践出真知…加油
maven中各个文件夹的含义–见名知意
maven本地仓库的配置
将maven全局配置的文件按复制到本地仓库文件夹下
在setings.xml文件夹下打开注释—
maven远程仓库的配置
“远程”仓库可能是你的公司拥有的建立在文件或HTTP服务器上的内部仓库(不是Apache的那个中央仓库，而是你们公司的私服，你们自己在局域网搭建的maven仓库)，用来在开发团队间共享私有构件和管理发布的。
由于maven服务器在国外,国内下载一些依赖的时候速度会比较慢,这时候可以设置以下远程仓库为中央仓库的镜像仓库
国内一般推荐阿里云的镜像仓库
可以指定多个镜像仓库,
仓库优先级的问题---->>>
项目在查找依赖的时候,先从本地仓库查找,找不大的话,如果配置了镜像仓库则从镜像仓库找,再找不到就从中央仓库找;
配置maven项目编译运行环境配置
当我们电脑中有很多个JDK的时候,我们需要指定一个maven的运行和编译环境
小结---->>
一般我们在配置maven环境时只需要配置用户环境,全局环境一般不做修改;
同时我们只需要在用户配置中添加本地仓库,远程仓库以及JDK版本信息就可以了;
在Idea中创建maven工程
现阶段不选择模板而是建一个标准的maven工程
maven标准目录结构—
目录名字不可以随便改，因为maven进行编译或者jar包生成操作的时候，是根据这个目录结构来找的，你若轻易动，那么久找不到了。
除此之外还有一些其他文件夹,由于没有打包项目,还没有展示
下面打包项目-----
打包结束后会生成一个target文件夹,用于存放项目打包后的文件;
这个跟我们在控制台上操做是一样的;
1,控制台进入pom.xml文件所在文件夹,
2,执行打包命令 mvn package
3,打包结束后运行---- java -cp 命令 来测试打包后的文件是否可以运行
maven中pom.xml的配置
基本的配置----->>
上面已经提到了
接下来需要实际操做—配置一些依赖
先做几个例子
配置依赖时爆红了,原因是我们没有更新依赖----
更新后就会下载依赖
如果不想每次手动同步,则需要设置一下让其自动同步------>>
Maven警告解决：Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platfor
在pom.xml中添加配置---->>>
<properties>
<project.build.sourceEncoding>
UTF-8
</project.build.sourceEncoding>
</properties>
添加自定义包的依赖
准备环境----->
一个自定义jar包
就用下面这个吧
依赖的特性与原则
依赖的传递性
新建一个maven 项目,
添加依赖------
在添加依赖的时候,会将依赖的依赖也一同导入到项目中,即依赖的传递性;
导入的一些内容可以直接用;
依赖关系----->>
第一原则----依赖的最短路径原则
“最短路径优先”意味着项目依赖关系树中路径最短的版本会被使用。
例如，假设A、B、C之间的依赖关系是A->B->C->D(2.0) 和A->E->(D1.0)，那么D(1.0)会被使用，因为A通过E到D的路径更短。
解析----
假如 A依赖B,B依赖C,C依赖D,D的版本为2.0版本
同时A又依赖E,E依赖D,D的版本为1.0版本,则 D的版本最终被确认为1.0版本;
例如创建Spring项目时引入context依赖会自动引入相关依赖
第二原则----第一原则失效时
当第一原则失效时,即路径长短一致时,该怎么确定版本呢?
可以在依赖的时候做排除动作
不用关注版本号,因为通过groupId 和artifactId 就能定位到jar包
继承与聚合
【1】继承关系：
如果A工程继承B工程，则代表A工程默认依赖B工程依赖的所有资源，且可以应用B工程中定义的所有资源信息。
被继承的工程（B工程）只能是POM工程。
注意：在父项目中放在<dependencyManagement>中的内容时不被子项目继承，不可以直接使用
放在<dependencyManagement>中的内容主要目的是进行版本管理。里面的内容在子项目中依赖时坐标只需要填写
和即可。（注意：如果子项目不希望使用父项目的版本，可以明确配置version）。
父工程是一个POM工程：
【2】聚合关系
当我们开发的工程拥有2个以上模块的时候，每个模块都是一个独立的功能集合。比如某大学系统中拥有搜索平台，学习平台，考试平台等。开发的时候每个平台都可以独立编译，测试，运行。这个时候我们就需要一个聚合工程。
在创建聚合工程的过程中，总的工程必须是一个POM工程（Maven Project）（聚合项目必须是一个pom类型的项目，jar项目war项目是没有办法做聚合工程的），各子模块可以是任意类型模块（Maven Module）。
聚合的前提：继承。
聚合包含了继承的特性。
聚合时多个项目的本质还是一个项目。这些项目被一个大的父项目包含。且这时父项目类型为pom类型。同时在父项目的pom.xml中出现表示包含的所有子模块。
聚合后生成的jar包目录结构----
插件的引入
编译器插件
当我们在一个工程中不想使用本地的jdk进行编辑,那么可以切换一下JDK的版本
资源拷贝插件
打包时只有放在resource的配置文件才会被打包
那如果想要打包非resource文件下的配置文件,那么就需要配置资源拷贝插件
<!-- 引入资源复制插件-->
<resources>
<resource>
<directory>src/main/java/com/gavin/app</directory>
<includes>
<include>**/*.xml</include>
</includes>
</resource>
<resource>
<directory>src/main/resources</directory>
<includes>
<include>**/*.xml</include>
<include>**/*.properties</include>
</includes>
</resource>
</resources>
配置好以后，相应位置下的配置文件都会被打包了：
tomcat插件
tomcat插件的引入需要在一个webapp工程中
新建一个maven工程,模板为webApp
之后在pom.xml中引入tomcat插件
在build下plugins plugin
<build>
<plugins>
<!-- 配置Tomcat插件 -->
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<!-- 配置Tomcat监听端口 -->
<port>8080</port>
<!-- 配置项目的访问路径(Application Context) -->
<path>/</path>
</configuration>
</plugin>
</plugins>
</build>
怎么证明我们配置好了呢?
由于tomcat插件不会自动运行,我们需要手动开启
开启方式------>>>
之后访问index.jsp
mvn 常用命令
install
本地安装， 包含编译，打包，安装到本地仓库
编译 - javac
打包 - jar， 将java代码打包为jar文件
安装到本地仓库 - 将打包的jar文件，保存到本地仓库目录中。
❀ clean
清除已编译信息。
删除工程中的target目录。
compile
只编译。 javac命令
❀ package
打包。 包含编译，打包两个功能。
install和package的区别：
package命令完成了项目编译、单元测试、打包功能，但没有把打好的可执行jar包（war包或其它形式的包）布署到本地maven仓库和远程maven私服仓库
install命令完成了项目编译、单元测试、打包功能，同时把打好的可执行jar包（war包或其它形式的包）布署到本地maven仓库，但没有布署到远程maven私服仓库
