5.Maven学习

最新推荐文章于 2024-09-13 15:25:08 发布

cs123HL

最新推荐文章于 2024-09-13 15:25:08 发布

阅读量17

点赞数

文章标签： maven 学习 python pycharm java

本文链接：https://blog.csdn.net/cs123HL/article/details/133094172

版权

尚硅谷-Maven教程笔记

1.maven：(项目管理工具)构建管理工具，依赖管理工具

第一章 Maven概述
第一节为什么要学习Maven？
1.Maven作为依赖管理工具
(1)jar包规模过大
(2) jar包的来源不统一
(3)jar包之间的依赖关系复杂
2.Maven作为构建管理工具
(1)在idea中，构建是idea替我们做的
(2)脱离idea环境仍需构建

3.总结：

管理规模庞大的 jar 包，需要专门工具。
脱离 IDE 环境执行构建操作，需要专门工具。

第二节什么是Maven？
一款专门为 Java 项目提供构建和依赖管理支持的工具
1.构建
Java 项目开发过程中，构建指的是使用『原材料生产产品』的过程

原材料：Java源代码，基于html的Thymeleaf文件，图片，配置文件......
产品：一个可以在服务器上运行的项目

构建过程包含的主要的环节：(清理，编译，测试，报告，打包，安装，部署)

清理：删除上一次构建的结果，为下一次构建做好准备
编译：Java 源程序编译成 *.class 字节码文件
测试：运行提前准备好的测试程序
报告：针对刚才测试的结果生成一个全面的信息
打包(Java工程：jar包，Web工程：war包)
安装：把一个 Maven 工程经过打包操作生成的 jar 包或 war 包存入 Maven 仓库
部署

　　　　-部署 jar 包：把一个 jar 包部署到 Nexus 私服服务器上
　　　　-部署 war 包：借助相关 Maven 插件(例如 cargo)，将 war 包部署到 Tomcat 服务器上
2.依赖
依赖管理中要解决的具体问题：
　　-jar 包的下载：使用 Maven 之后，jar 包会从规范的远程仓库下载到本地
　　-jar 包之间的依赖：通过依赖的传递性自动完成
　　-jar 包之间的冲突：通过对依赖的配置进行调整，让某些jar包不会被导入
3.Maven工作机制

第二章 Maven核心程序解压和配置

第一节 Maven核心程序解压和配置

1.Maven下载
去官网去下载，历史版本点击archive
2.解压Maven核心程序
核心程序压缩包：apache-maven-3.8.4-bin.zip
在解压目录中，我们需要着重关注 Maven 的核心配置文件：conf/settings.xml
3.指定本地仓库
本地仓库这个目录，我们手动创建一个空的目录即可
<localRepository>D:\maven-repository</localRepository>
4.配置阿里云提供的镜像仓库
<mirror>
　　<id>nexus-aliyun</id>
　　<mirrorOf>central</mirrorOf>
　　<name>Nexus aliyun</name>
　　<url>http://maven.aliyun.com/nexus/content/groups/public</url>
</mirror>
5、配置 Maven 工程的基础 JDK 版本
如果按照默认配置运行，Java 工程使用的默认 JDK 版本是 1.5，
而我们熟悉和常用的是 JDK 1.8 版本。修改配置的方式是：
将 profile 标签整个复制到 settings.xml 文件的 profiles 标签内

 1     <profile>
 2       <id>jdk-1.8</id>
 3       <activation>
 4         <activeByDefault>true</activeByDefault>
 5         <jdk>1.8</jdk>
 6       </activation>
 7       <properties>
 8         <maven.compiler.source>1.8</maven.compiler.source>
 9         <maven.compiler.target>1.8</maven.compiler.target>
10         <maven.compiler.compilerVersion>1.8</maven.compiler.compilerVersion>
11       </properties>
12     </profile>

View Code

第二节配置环境变量
配置之前先要把JAVA_HOME配置好
配置MAVEN_HOME
配置Path

第三章使用Maven：命令行环境
第一节实验一：根据坐标创建 Maven 工程
1、Maven 核心概念：坐标Maven中的坐标：(GAV)
使用三个『向量』在『Maven的仓库』中唯一的定位到一个『jar』包。
groupId：公司或组织域名的倒序，通常也会加上项目名称(组织标识，通常也会加上项目名称)
例如：com.atguigu.maven
artifactId：模块的名称，将来作为 Maven 工程的工程名(模块标识)(如果一个项目只有一个模块，那么就是项目标识)
version：模块的版本号，根据自己的需要设定(模块的版本号)
例如：SNAPSHOT 表示快照版本，正在迭代过程中，不稳定的版本
例如：RELEASE 表示正式版本

2.坐标和仓库中 jar 包的存储路径之间的对应关系
坐标：
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
上面坐标对应的 jar 包在 Maven 本地仓库中的位置：
Maven本地仓库根目录\javax\servlet\servlet-api\2.5\servlet-api-2.5.jar一定要学会根据坐标到本地仓库中找到对应的 jar 包。
2.实验操作
(1)通过命令行创建maven工程
(2)pom.xml文件标签代表什么意思
3.Maven核心概念：POM
(1)POM：项目对象模型
4.Maven核心概念：约定的目录结构
基础的配置在超级pom中定义好了，比如约定的目录结构
(1)各个目录的作用

(2)约定目录结构的意义
Maven 为了让构建过程能够尽可能自动化完成，所以必须约定目录结构的作用。例如：Maven 执行编译操作，
必须先去 Java 源程序目录读取 Java 源代码，然后执行编译，最后把编译结果存放在 target 目录
(3)约定大于配置

第二节实验二：在 Maven 工程中编写代码
1.主体程序2.测试程序
(1)静态导包
(2)junit的Assert断言机制(assert：断言)，断言是做测试的时候经常用的一种技术
(3)测试类类名和测试方法方法名，习惯把Test放到最后
(4)清楚测试类的一个整体流程：测试哪个类，就创建哪个类的对象；测试哪个方法，就调用哪个方法
(测试方法上要加@Test注解)

第三节实验三：执行 Maven 的构建命令(清理，编译，测试，打包，安装)
1.要求
mvn -v 命令和构建操作无关，只要正确配置了 PATH，在任何目录下执行都可以。
而构建相关的命令要在 pom.xml 所在目录下运行——操作哪个工程，就进入这个工程的 pom.xml 目录。
2.清理操作
mvn clean 效果：删除target目录
3.编译操作
主程序编译：mvn compile
测试程序编译：mvn test-compile
主体程序编译结果存放的目录：target/classes
测试程序编译结果存放的目录：target/test-classes
4.测试操作
mvn test
测试的报告存放的目录：target/surefire-reports
5.打包操作
mvn package
打包的结果——jar 包，存放的目录：target
打包：java项目打jar包，web项目打war包
6.安装操作
mvn install
mvn clean install 清理后安装
安装的效果是将本地构建过程中生成的 jar 包存入 Maven 本地仓库。这个 jar 包在 Maven 仓库中的路径是根据它的坐标生成的。
坐标信息如下：
<groupId>com.atguigu.maven</groupId>
<artifactId>pro01-maven-java</artifactId>
<version>1.0-SNAPSHOT</version>
在Maven仓库中生成的路径如下：
D:\maven-rep1026\com\atguigu\maven\pro01-maven-java\1.0-SNAPSHOT\pro01-maven-java-1.0-SNAPSHOT.jar
另外，安装操作还会将 pom.xml 文件转换为 XXX.pom 文件一起存入本地仓库。所以我们在 Maven 的本地仓库中想看一个 jar
包原始的 pom.xml 文件时，查看对应 XXX.pom 文件即可，它们是名字发生了改变，本质上是同一个文件。

第四节实验四：创建 Maven 版的 Web 工程(通过命令创建)
第五节实验五：让 Web 工程依赖 Java 工程
第六节实验六：测试依赖的范围
1.依赖范围
标签的位置：dependencies/dependency/scope
标签的可选值：compile/test/provided/system/runtime/import(主要了解前三个，后面三个import重要一点)
(1)compile和test对比

(2)compile和provided对比

(3)结论
compile：通常使用的第三方框架的 jar 包这样在项目实际运行时真正要用到的 jar 包都是以 compile 范围进行依赖的。比如 SSM 框架所需jar包。
test：测试过程中使用的 jar 包，以 test 范围依赖进来。比如 junit。
provided：在开发过程中需要用到的“服务器上的 jar 包”通常以 provided 范围依赖进来。
比如 servlet-api、jsp-api。而这个范围的 jar 包之所以不参与部署、不放进 war 包，
就是避免和服务器上已有的同类 jar 包产生冲突，同时减轻服务器的负担。说白了就是：“服务器上已经有了，你就别带啦！”

第七节实验七：测试依赖的传递性
1、依赖的传递性
#①概念
A 依赖 B，B 依赖 C，那么在 A 没有配置对 C 的依赖的情况下，A 里面能不能直接使用 C？

#②传递的原则
在 A 依赖 B，B 依赖 C 的前提下，C 是否能够传递到 A，取决于 B 依赖 C 时使用的依赖范围。
·B 依赖 C 时使用 compile 范围：可以传递
·B 依赖 C 时使用 test 或 provided 范围：不能传递，所以需要这样的 jar 包时，就必须在需要的地方明确配置依赖才可以

第八节实验八：测试依赖的排除
第九节实验九：继承
1、概念
Maven工程之间，A 工程继承 B 工程

B 工程：父工程
A 工程：子工程

本质上是 A 工程的 pom.xml 中的配置继承了 B 工程中 pom.xml 的配置。
2、作用在父工程中统一管理项目中的依赖信息，具体来说是管理依赖信息的版本。
它的背景是：

对一个比较大型的项目进行了模块拆分。
一个 project 下面，创建了很多个 module。
每一个 module 都需要配置自己的依赖信息。

它背后的需求是：

在每一个 module 中各自维护各自的依赖信息很容易发生出入，不易统一管理。
使用同一个框架内的不同 jar 包，它们应该是同一个版本，所以整个项目中使用的框架版本需要统一。
使用框架时所需要的 jar 包组合(或者说依赖信息组合)需要经过长期摸索和反复调试，最终确定一个可用组合。这个耗费很大精力总结出来的方案不应该在新的项目中重新摸索。

通过在父工程中为整个项目维护依赖信息的组合既保证了整个项目使用规范、准确的 jar 包；

又能够将以往的经验沉淀下来，节约时间和精力。

第十节实验十：聚合
1.Maven中的聚合
使用一个“总工程”将各个“模块工程”汇集起来，作为一个整体对应完整的项目。