maven管理了所有jar包的导入
maven
简介
why
目前的技术
目前存在的问题
- 一个项目就是一个工程
- 项目庞大,不适合用package划分模块
- 一个模块对应一个工程
- 借助maven拆分成多个工程,利于分工协作
- 项目中需要的jar包必须手动复制、粘贴 到 WEB-INF/lib
- 同一jar包重复出现在不同项目工程
- jar包仅保存一份
- 保存在 maven 仓库中,需要时
引用
即可
- 同一jar包重复出现在不同项目工程
- jar包需要找资源
- 借助maven以一种规范的方式下载jar包,框架或第三方工具的jar包按同一的规范存放在maven的中央仓库
- jar包所依赖的其他jar包需要手动加入到项目中
what
服务于java平台
自动化构建工具
Make->Ant->Maven->Gradle
构建
以 “java源文件”、“框架配置文件”、“JSP”、“HTML”、“图片”等资源为“原材料”,“生产”一个可以运行的项目的过程
编译
- .java文件 -> 编译 -> Class 字节码文件.class -> 交给JVM去执行
搭建
部署
动态web工程-> 编译、部署 -> 编译结果
运行时环境——JRE
- 一组jar包的引用,不是jar包
- 不是目录
工程目录VS编译结果
所有的路径或配置文件中配置的类路径等都是以编译结果的目录结构为标准的
构建环节
清理
将以前编译得到的就得.class字节码文件删除
编译
将.java源程序变成.class字节码文件
测试
自动测试,自动调用junit程序
报告
测试程序 执行的结果
打包
动态web工程 -> war包
java工程 -> jar包
安装
Maven特定概念——将打包得到的文件复制到 “仓库” 中的制定位置
部署
将动态Web工程生成的war包赋值到Servlet容器的制定目录下,使其可以运行
安装Maven核心程序
配置 JAVA_HOME
解压Maven核心程序的压缩包,放在非中文无空格路径下
配置Maven的环境变量
MAVEN_HOME
path
验证
运行 mvn -v查看Maven的版本
Maven核心概念
约定的目录结构
只要有 pom.xml
,Eclipse和IDEA都可以识别为Maven项目
Hello
| —-src
| —-main
| —-java
| —-resources
| —-test
| —-java
| —-resources
| —-pom.xml
- 根目录:工程名
- src目录:源码
- pom.xml:Maven工程的核心配置文件
- main目录:存放主程序
- test目录:存放测试程序
- java目录:存放Java源码
- resources目录:存放框架或其他工具的配置文件
要实现自动构建:
- 以配置的方式明确告诉框架
- 遵守框架内部已经存在的约定
约定 > 配置 > 编码
POM
Project Object Model:项目对象模型
pom.xml
与构建过程相关的一切设置都在这个文件
相当于 web.xml相对于动态Web工程
坐标
数学上的坐标
- 平面上,使用两个向量唯一表示一个点
- 空间上,使用三个向量唯一表示一个点
Maven的坐标
三个向量在仓库中唯一定位一个Maven工程
groupId
公司或组织域名倒序+项目名
1
<groupid>com.atguigu.maven</groupid>
artifactId
模块的名称
1
<artifactid>Hello</artifactid>
version
版本
1
<version>1.0.0</version>
- SNAPSHOT(快照,开发版)
- alpha(内测版)
- beta(公测版)
- Release | RC(发布版)
- GA(正常版)
Maven工程的坐标与仓库中路径的对应关系
1
2
3<groupid>org.springframework</groupid>
<artifactid>spring-core</artifactid>
<version>4.0.0.RELEASE</version>org\springframework\spring-core\4.0.0.RELEASE\spring-core-4.0.0.RELEASE
依赖
Maven解析依赖信息时,会到本地仓库中找依赖的jar包
- 自己开发的Maven工程,使用Install安装后就可进入仓库
依赖的范围
三个取值
被定义为 | compile范围的依赖 | test范围的依赖 | provided范围的依赖 |
---|---|---|---|
对主程序是否可见 | 是 | 否 | 是 |
对测试是否可见 | 是 | 是 | 是 |
是否参与打包\部署 | 是 | 否 | 否 |
例子 | spring-core | junit | Tomcat:servlet-api.jar |
compile范围的依赖 VS test范围的依赖
compile范围的依赖 VS provided范围的依赖
依赖的传递性
非
compile
范围的依赖不能传递
直接依赖
继承依赖
依赖的排除
什么时候需要
排除
1 | <dependency> |
查找groupId 和 artifactId
依赖的原则
作用:解决模块工程之间的jar包冲突问题
路径长度不同
- 就近原则:路径最短 14
路径长度相同
- 先声明者优先:参照当前项目的dependency标签声明顺序
统一管理依赖的版本
- properities标签内使用
自定义标签
统一声明版本号 - 在需要同一版本的位置,使用
${自定义标签名}
引用声明
1 | <project> |
1 | <dependencies> |
仓库
分类
本地仓库:部署在当前主机上的仓库,服务于主机上所有Maven工程
远程仓库
私服Nexus——局域网范围
搭建在局域网环境中,为局域网中所有Maven工程服务
中央仓库
为所有Maven工程服务
中央仓库镜像
分担中央仓库的流量;提速
仓库中的内容——Maven工程
- Maven自身所需的插件
- 第三方框架或工具的jar包(jdk,开发)
- 自己开发的Maven工程
生命周期/插件/目标
各个构建环节执行的顺序
Maven的核心程序中定义了抽象的生命周期
clean Lifecycle——构建之前的清理
- pre-clean:执行一些需要在clean之前完成的工作
- clean:移除所有上一次构建生成的文件
- post-clean:执行一些需要在clean之后立刻完成的工作
Default Lifecycle——构建的核心部分
编译、测试、打包、安装、部署
Maven核心程序为了更好的实现自动化构建——
`不论现在执行生命周期中的哪个阶段,都是从这个生命周期最开始的阶段开始`
Site Lifecycle——生成项目报告、站点、发布站点
- pre-site:执行一些需要在生成站点之前完成的工作
- site:生成项目的站点文档
- post-site:执行需要在生成站点文档之后需要做的工作;为部署做准备
- site-deploy:将生成的站点文档部署到特定服务器上
插件和目标
目标:生命周期的各个阶段仅定义了要执行什么
插件:相似的目标由特定的插件完成
生命周期阶段 | 插件目标 | 插件 |
---|---|---|
compile | compile | maven-compiler-plugin:3.1:compile |
test-compile | test-compile | maven-compiler-plugin:3.1:compile |
命令 调用 插件 实现 插件目标
继承
需求:统一管理各个模块工程中对
junit[test范围的依赖]
依赖的版本解决思路:
将
junit
依赖版本统一提取到 “父” 工程中,在子工程中声明依赖时,不指定版本,以父工程中统一设定的为准。
创建一个Maven工程为父工程
打包方式:pom
在子工程中声明对父工程的引用
1
2
3
4
5
6
7
8
9
10
11
12<!--子工程的pom.xml -->
<project>
<!-- 子工程中声明父工程 -->
<parent>
<groupId>com.atguigu.maven</groupId>
<artifactId>Parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
<!-- 以当前工程的pom.xml文件为基准的父工程pom.xml的相对路径 -->
<relativePath>../Parent/pom.xml</relativePath>
</parent>
</project>将子工程的坐标中与父工程中重复内容删除
在父工程中统一junit的依赖
1
2
3
4
5
6
7
8
9
10
11
12
13
14<!--父工程的pom.xml -->
<project>
<!-- 配置依赖的管理 -->
<dependencyManagement>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.0</version>
<scope>test</scope>
</dependency>
</dependencies>
</dependencyManagement>
</project>在子工程中删除 junit 依赖的版本号部分
聚合
解决各个模块工程的安装——一键安装各个模块工程
配置方式
在一个 “聚合工程” 中配置各个参与聚合的模块
聚合工程——Parent
```xml
<!-- 配置聚合 --> <modules> <!--指定各个子工程的相对路径--> <module>../HelloFriend</module> <module>../Hello</module> </modules>
</project>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
- 使用方式:在聚合工程pom.xml上右键 -> Run as -> Maven Install
- 聚合时,Maven可识别各模块工程之间的依赖关系
<div style="page-break-after:always"></div>
## 常用Maven命令
> mvn [plugin-name]:[goal-name]
> 执行与构建过程相关的Maven命令,必须进入pox.xml所在的目录
- 编译、测试、打包、部署
### mvn clean——清理
清理[项目名]\target 文件夹
![image-20210131191738706](1-maven/image-20210131191738706.png)
### mvn compile——编译主程序
> 阶段(不重要)
![image-20210201094054999](1-maven/image-20210201094054999.png)
![image-20210201105352326](1-maven/image-20210201105352326.png)
### mvn test-compile——编译测试程序
> 阶段(不重要)
![image-20210201093938340](1-maven/image-20210201093938340.png)
![image-20210201105424136](1-maven/image-20210201105424136.png)
### mvn test——执行测试
> 阶段(不重要)
![image-20210201094358240](1-maven/image-20210201094358240.png)
![image-20210201105445081](1-maven/image-20210201105445081.png)
> 测试报告
![image-20210131191456139](1-maven/image-20210131191456139.png)
### mvn exec:java -Dexec.mainClass="com.atguigu.maven.Hello"
> 单独启动某个带有main方法的class
### mvn package——打包
> 阶段(不重要)
![image-20210201094257799](1-maven/image-20210201094257799.png)
![image-20210201105512519](1-maven/image-20210201105512519.png)
> 打包后的结果
![image-20210131191600654](1-maven/image-20210131191600654.png)
![image-20210131191637800](1-maven/image-20210131191637800.png)
![image-20210201094452112](1-maven/image-20210201094452112.png)
### mvn install——将当前Maven工程安装到mvn仓库
![image-20210201105640916](1-maven/image-20210201105640916.png)
![image-20210201105544402](1-maven/image-20210201105544402.png)
### mvn site——生成站点文档
### mvn deploy——将打包的文件发到远程参考
<div style="page-break-after:always"></div>
## 例子
### 1. 熟悉目录结构
![image-20210131180120518](1-maven/image-20210131180120518.png)
```xml
<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>
<name>Hello</name>
<!-- 基本设置 The Basics -->
<groupId>com.atguigu.maven</groupId>
<artifactId>Hello</artifactId>
<version>0.0.1-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>Hello</artifactId>
<version>4.0</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
1 | package com.atguigu.maven; |
1 | package com.atguigu.maven; |
2. 依赖的导入与范围
pom.xml
1 |
|
HelloFriend
1 | package com.atguigu.maven; |
HelloFriendTest.java
1 | package com.atguigu.maven; |
Hello根目录下 执行 mvn install
3. 依赖传递
pom.xml
1 | <dependencies> |
引用
,仅在Maven仓库中保留一份
MakeFriends.java
1 | package com.atguigu.maven; |
MakeFriendsTest
1 | package com.atguigu.maven; |
Maven配置
指定默认JDK版本
问题:JDK默认1.5
解决
maven -> settings.xml
profiles 标签
1 | <profiles> |
修改本地仓库位置
Maven的核心程序仅定义了抽象的生命周期,但具体的工作必须由特定插件完成,插件不在Maven的核心程序中
当执行的Maven命令需要用到某些插件,Maven核心程序会先到本地仓库中查找
本地仓库的默认位置:[当前用户的家目录]\.m2\repository
Maven核心程序如果在本地仓库中找不到所需插件,则会连接外网,到中央仓库下载
若无法连接外网,构建失败
解决办法
修改默认本地仓库的位置
Maven的解压目录\conf\settings.xml
找到localRepository标签
修改镜像路径
问题:下载速度慢
解决办法:插件下载路径修改为国内镜像
1 | <!--seetings.xml--> |
IDEA中Maven
配置
File -> Settings :仅为当前项目配置
File -> New Project Settings:为所有项目
为所有项目配置
修改Maven核心程序位置
- 自动构建Maven工程
手动新建文件夹时,Maven不会自动识别,要手动将其标记为Maven文件目录结构
项目预览右键
IDEA Maven Java项目
Project Structure
创建Maven Java项目
勾选后会联网下载对应的Maven工程框架与相关依赖
打开项目后会下载依赖到仓库,在 pom.xml
中引用插件
创建简单Maven Java工程
1. 创建
1 | <dependency> |
编写主程序代码
1 | public class Hello { |
编写测试程序
1 | public class HelloTest { |
IDEA中执行Maven命令
创建Maven编译器
创建Web项目
修改打包方式
1 | <!-- Web工程打包方式为War --> |
新建WEB文件夹与配置
配置Tomcat编译器
新建
配置编译器属性
配置打包部署属性
An artifact is an assembly of your project assets that you put together to test, deploy or distribute your software solution or its part. Examples are a collection of compiled Java classes or a Java application packaged in a Java archive, a Web application as a directory structure or a Web application archive, etc.
即编译后的Java类,Web资源等的整合,用以测试、部署等工作。再白话一点,就是说某个module要如何打包,例如war exploded、war、jar、ear等等这种打包形式。某个module有了 Artifacts 就可以部署到应用服务器中了
*jar:Java ARchive,通常用于聚合大量的Java类文件、相关的元数据和资源(文本、图片等)文件到一个文件,以便分发Java平台应用软件或库;*
*war:Web application ARchive,一种JAR文件,其中包含用来分发的JSP、Java Servlet、Java类、XML文件、标签库、静态网页(HTML和相关文件),以及构成Web应用程序的其他资源;*
*exploded:在这里你可以理解为展开,不压缩的意思。也就是war、jar等产出物没压缩前的目录结构。建议在开发的时候使用这种模式,便于修改了文件的效果立刻显现出来。
中文乱码
tomcat/conf/logging.properties
1 | java.util.logging.ConsoleHandler.encoding = GBK |
eclipse中Maven
Maven插件的设置
Installations
指定Maven核心程序的位置——用自己安装的
User Settings
指定本地仓库的位置
指定conf/settings.xml位置,进而获取本地仓库的位置
基本操作
创建Maven版Java工程
创建Maven版Web工程
1. 创建
打包方式区分 java工程 与 Web工程
2. 使Eclipse识别为Web工程——web.xml
web.xml 又称部署描述符
去掉Dynamic Web Module -> Apply ->
勾选Dynamic Web Module ->Further cofiguration available
3. 导入servlet-api.jar——provided范围的依赖
eclipse做法
Maven做法
1 | <dependencies> |
servlet-api.jar为provided范围的依赖
依赖默认为compile范围
1 | <dependency> |
4. 部署到Tomcat
1 | <project> |
导入Maven工程
eclipse工程必须有的配置文件
- .settings
- .classpath
- .project
只要有pom.xml的工程都可作为maven工程导入
建在工作区外的Maven工程 Eclipse无法将其复制到工作区
执行Maven命令
Maven build——Maven构建
- compile
- test-compile
eclipse中执行Maven命令是严格按照Maven规则
项目中的依赖必须在Maven中找到