maven详解2020

maven概述

1.概念

Maven这个单词来自于意第绪语(犹太语),意为知识的积累,最初在Jakata Turbine项目中用来简化构建过程。当时有一些项目(有各自Ant build文件),仅有细微的差别,而JAR文件都由CVS来维护。于是希望有一种标准化的方式构建项目,一个清晰的方式定义项目的组成,一个容易的方式发布项目的信息,以及一种简单的方式在多个项目中共享JARs。于是maven诞生了。

在我们的日常项目中,maven不仅是一个依赖管理工具,有效的帮我们管理项目中需要使用到的各种依赖,也是一个项目构建工具,可以通过其内置的项目模板(也称为骨架 archetype),构建常规的项目(jar war等)。使用的maven项目的对象模型(pom-project object model),可以通过一小段描述信息来管理项目的构建,报告和文档的管理。

2.为什么要用maven

这里举个生活中的例子,比如此时的你想要配一台主机来玩游戏,那么你需要去选购组成这个主机的各种配件,进而需要去了解各种配件的性能,配件之间的兼容性,组装好后还需要自己装操作系统和驱动程序,这使得不熟悉组装电脑主机的你需要花费大量的时间,最后的结果还可能是你的主机运行不稳定,经常蓝屏。在这个时候突然有个人告诉你,你可以去某个知名的电商平台,你可以浏览一下主流的机型,选择了你需要的配置,然后下单、付款。接着PC供应商帮我组装电脑、安装操作系统和驱动程序,物流公司将电脑送到我的家里,你接上显示器、电源、鼠标和键盘就能直接使用了。这为你节省了大量时间,而且这台电脑十分稳定,商家在把电脑发送给你之前已经进行了很好的测试。这难道不香吗?

在日常的团队开发中,这种找配件组装"主机"的方式,显得更杂乱无序,既无法有效的确保依赖之间的兼容性,又不能保证资源的重用型,且无法摆脱对代码工具的依赖,对于大型项目的开发,框架的整合,依赖的管理带来了很大的困扰。而使用maven这个强大的依赖管理,项目工具,你的问题将迎刃而解,它将帮我们完成,自动关联,拉取依赖,升级框架,依赖有效管理,自动测试,打包部署等,所以我们要说maven :yes。

maven安装与简单使用

1.安装

1.1 下载

前往https://maven.apache.org/download.cgi下载最新版的Maven程序

1.2 解压与环境变量的配置

maven详解2020_第1张图片
然后将文件解压到你自己想要存放的目录下(如D:\Program Files (x86)\apache-maven-3.6.1):
maven详解2020_第2张图片
环境变量配置:
新建环境变量MAVEN_HOME,赋值D:\Program Files (x86)\apache-maven-3.6.1
maven详解2020_第3张图片

编辑环境变量Path,追加%MAVEN_HOME%\bin;
maven详解2020_第4张图片
至此,maven已经完成了安装,我们可以通过DOS命令检查一下我们是否安装成功:
maven详解2020_第5张图片

1.3 修改本地仓库及镜像

maven仓库引用结构

本地仓库(local)->自己在磁盘创建的用以存放资源的文件夹;
私服镜像(aliyun)->常使用国内资源镜像,提升资源拉取速度;
中央仓库central->maven官方仓库资源。

maven资源拉取方式

在maven的pom配置文件中国配置项目所需的依赖,在项目保存时,maven将自动通过你配置的坐标路径去拉取依赖资源,首先会去扫描本地仓库,若有,直接获取,若无,将会前往所配置的私服镜像去拉取相关的依赖资源。

仓库配置

进入你的maven文件安装目录,找到conf配置文件夹,修改setting.xml,修改本地仓库位置
maven详解2020_第6张图片
修改镜像源,拉取国内资源的路径配置 setting.xml

  
    
      alimaven
      aliyun maven
      http://maven.aliyun.com/nexus/content/groups/public/
      central        
    
  

通过以上步骤,已经完成了maven的安装与简单配置。

1.4 maven常用命令

maven comand

// 编译源代码
mvn compile
// 运行测试
mvn test
// 项目打包
mvn package
// 清除产生的项目
mvn clean
//项目打包时跳过测试
mvn package -Dmaven.test.skip=ture

1.5 maven坐标

maven pointer

//定义当前 Maven 项目从属的实际项目,表述形式同 Java 包名的表述方式类似,通常与域名反向一一对应
groupId
//定义实际项目中的一个 Maven 项目(实际项目中的一个模块),表述形式为当前项目名
artifactId
//定义 Maven 当前所处的版本
version
//定义 Maven 项目的打包方式
packaging
//定义构件输出的附属构件
classifier
//依赖描述:
type: 依赖的类型
scope: 依赖的范围
optional: 标记依赖是否可选
exclusions: 用来排除传递性依赖

2.maven使用

2.1 构建一个简单的项目

简单的java se项目 jar

# 在你的磁盘中新建文件加,用以存放maven创建的项目 然后cmd 切换到你的文件夹路径,执行以下代码片段
# 生成java se 项目
mvn archetype:generate -DarchetypeCatalog=internal -DgroupId=com.zglt.build -DartifactId=demo
# cmd 切换到你的项目路径下即在pom.xml的目录下运行以下代码
mvn clean compile exec:java -Dexec.mainClass="com.zglt.build.App"
# 将项目程序打包,用以发布
mvn package

maven构建普通项目的结构

└─src                      	classPath项目源码根目录
   ├─main                	主要
   │  ├─java              	java源码
   │  │  └─com            
   │  │      └─zglt
   │  │          └─build  	com.zglt.build包名
   │  └─resources      		资源: 配置文件(约定优于配置)
   └─test                 	用于单元测试的相关包
       └─java
           └─com
               └─zglt
                   └─build
pom.xml 					项目对象模型配置(依赖管理等)

pom.xml配置


  4.0.0
  
  com.zglt.build
  demo
  1.0-SNAPSHOT
  
  jar
  
  demo
  
  http://maven.apache.org


  
    
    UTF-8
  

  
  
    
    
      junit
      junit
      3.8.1
      test
    
  

maven生命周期

1.概念

maven基于构建生命周期的中心概念,定义了项目构建的每一个阶段过程,对于构建项目的人员,这意味着只需要学习一小堆命令即可构建任何Maven项目,POM将确保他们获得所需的结果。

2.默认生命周期

检验
(validate) - 验证项目是否正确,所有必要的信息是否可用;
初始化
(initialize)项目文件配置初始化;
编译
(compile) - 编译项目的源代码;
单元测试
(test) - 使用合适的单元测试框架测试编译的源代码(这些测试不应该要求代码被打包或部署)
打包
(package) - 采用编译的代码,并以其可分配格式(如JAR)进行打包;
集成测试
(verify) - 对集成测试的结果执行任何检查,以确保满足质量标准;
安装
(install) - 将软件包安装到本地存储库中,用作本地其他项目的依赖项;
部署
(deploy) - 在构建环境中完成,将最终的包复制到远程存储库以与其他开发人员和项目共享。

maven依赖管理

1.依赖范围

a.compile 默认的范围,编译测试运行都有效;
b.provided 编译和测试时有效,最后是在运行的时候不会被加入,如servlet api;
c.runtime 在测试和运行时有效,如MYSQL JDBC DRIVER;
d.test 在测试时有效,如junit;
e. system 与本机系统相关联,编译/测试/运行时有效;
f. import 导入的范围,它只在使用dependencyManagement中,表示从其他pom中导入dependecy的配置。

2.依赖传递

在maven中,依赖是可以传递的,就是说假设存在三个项目,分别是项目c,项目b以及项目a,假设a依赖于b,b依赖于c,那么我们可以根据Maven项目依赖的特征不难推出项目a也依赖于c(只有编译时和运行时依赖是传递的),所谓的传递依赖,简单的说,a的运行需要b的存在,那么a依赖于b,而b的运行又需要c的存在,那么b依赖于c,根据需求传递,那么可以推出a的运行需要c的存在。

3.依赖冲突

同理在一个项目中,既然存在依赖之间的传递,那么当依赖发生冲突的时候,maven又是怎么进行依赖管理的呢,我们举例说明什么是依赖冲突,假设有如下的依赖树:

最短路径原则

A
|		B
|		|		| C
|		C

可以看出项目A存在有2个直接的依赖B,C和一个间接的依赖C,此时对于项目A来说,将会有两个版本的C,从而产生版本冲突,也就是是所说的依赖冲突,maven在解决如下冲突时,使用最短路径原则,亦即这里的A项目将直接依赖最短路径的C。

优先声明原则

A
|		B
|		|		| C 1.0  优先
|		E
|		|		| C 2.0

可以看出项目A存在有2个直接的依赖B,E和2个间接的依赖C,此时对于项目A来说,将会有两个版本的C且路径距离相同,从而产生依赖冲突,maven在解决如下冲突时,使用优先声明原则,亦即这里的A项目将直接依赖于优先在pom中声明的C 1.0版本。

你可能感兴趣的:(java,maven)