2025年maven的使用教程_maven使用教程

maven

面临的问题

一个项目就是一个工程。如果项目非常大，最好是每一个模块对应一个工程。借助maven可以将一个项目拆分成多个工程

项目中需要的jar必须要手动”复制”,”粘贴”到WEB-INF/lib目录下，带来的问题是:同样的jar包文件重复出现在不同的项目工程中,浪费空间。maven可以将jar仅仅保存在”仓库”中,有需要使用的工程”引用”这个文件接口，并不需要真的把jar包复制过来

jar包需要别人替我们准备好，或到官网下载。不同技术的官网提供jar包下载的形式是五花八门的，有些技术的官网就是通过maven下载的，如果是以不规范的方式下载的jar包，那么其中的内容可能是不规范的。借助maven可以以一种规范的方式下载jar包，因为所有指明框架或第三方工具的jar包以及按照统一规范的方式下载的jar包，内容也是可靠的。

一个jar包以来的其他jar包需要自己手动加入到项目中。
如:A包依赖于B包，B包依赖于C包…

maven是什么
以 java源文件,框架配置文件,jsp,html,图片等资源为原材料,去生产一个可以运行的项目的过程

构建过程中的各个环节

清理清理以前的class字节码文件

编译:编译成class文件

测试:自动测试，自动调用junit

报告:测试程序执行的结果

打包:动态web打war，java工程打jar

安装:maven特定的概念–将打包得到的文件复制到”仓库”中的指定位置

部署:将动态web工程生成的war包复制到servlet容器的指定目录下，使其可以运行

maven核心概念

约定的目录结构

POM

坐标

依赖

仓库

生命周期/插件/目标

继承

耦合

目录结构

maven约定目录结构

Hello
|——src
|——-|——-main
|——-|———|———java
|——-|———|———resource
|——-|——–test
|——-|———|———java
|——-|———|———resource
|——-pom.xml(maven核心配置文件)

注意:
maven的核心程序中仅仅定义了抽象的生命周期，但是具体的工作必须由特定的插件来完成，而插件本身并不包含在maven的核心程序中。当我们执行的maven命令需要用到某些插件时，maven核心程序会首先到本地仓库中查找，如果找不到则去自动联网下载

POM

pom.xml对于maven工程是核心配置文件，与构建过程相关的一切设置都在这个文件中进行配置

坐标

使用下面三个向量在仓库中为一定为一个maven工程

groupid 公司或组织域名倒序+项目名

artifactid 模块名

version 版本

仓库

本地仓库

远程仓库

私服搭建在局域网，为所有局域网内的maven工程服务

中央仓库

中央仓库镜像

仓库中保存的内容:

maven自身锁需要的插件

第三方框架或工具的jar包

我们自己开发的maven工程

依赖

maven解析依赖信息时回到本地仓库中查找被依赖的jar包，对于我们自己开发的maven工程，使用install命令安装后就可以进入仓库
依赖的范围

compile

对主程序是否有效:有效

对测试程序是否有效:有效

是否参与打包:参与

test

对主程序是否有效:无效

对测试程序是否有效:有效

是否参与打包:不参与

典型例子:junit

provided范围依赖

对主程序是否有效:有效

对测试程序是否有效:有效

是否参与打包:不参与

是否参与部署:不参与

典型例子:servlet.jar

生命周期

各个环节构建的顺序:不能打乱顺序，必须按照既定的正确顺序来执行,maven的核心程序中定义了抽象的生命周期，生命周期中各个阶段的具体任务是由插件来完成的，maven无论现在要执行生命周期的哪一个阶段，都是从这个生命周期最初的位置开始执行的。

插件和目标

生命周期的各个阶段紧紧定义了要执行的任务是什么

各个阶段和插件的目标是对应的

相似的目标由特定的插件来完成

可以将目标看做”调用插件功能的命令”

依赖

依赖的传递性
如果A依赖B，B依赖C，那么A依赖C。
可以传递的依赖不必在每个模块工程中都部署声明，在最下面的工程中依赖一次即可
注意 :非compile依赖没有传递性

依赖的排除



	
	


/pre>
p>依赖的原则

解决依赖之间冲突问题:maven解决依赖冲突问题的方法是就近原则

/p>
p>

统一管理依赖的版本

如果大量的包需要更改版本，需要手动去改，很麻烦。

建议的配置方式:
/p>
p>使用properties标签内使用自定义标签统一生命版本号
/p>
p>在需要统一版本的位置，使用${自定义标签名}引用生命的版本号
/p>
p>其实properties标签配合自定义标签声明数据的配置不是只能用于声明依赖的版本号。凡是需要统一声明后再引用的场合都可以使用。
/p>
h4>继承
/h4>
p>现状
/p>
p>hello依赖的junit:4.0
/p>
p>hellofriend依赖的junit:4.1
/p>
p>makefriend依赖的junit:4.2

由于test范围的依赖没有传递性，必然会分散在各个模块中，很容易造成版本不一致。

需求:统一管理各个模块工程中对Junit依赖的版本

解决思路:将junit依赖统一提取到”父”工程中,在子工程中声明junit依赖不定版本，以父工程中统一设定的版本为准。
/p>
p>创建一个maven工程作为父工程.注意:打包的方式pom
/p>
p>在子工程的坐标中声明对父工程的引用
/p>
p>将子工程的坐标与父工程坐标重复的删除
/p>
p>在父工程中统一junit依赖
/p>
p>在子工程中删除Junit依赖的版本号
/p>
p>注意:配置继承后，执行安装命令时要先安装父工程
/p>
h4>聚合
/h4>
p>作用:一键安装各个模块工程

配置方式:在一个“总的聚合工程”中配置各个参与聚合模块
/p>
h4>maven的部署
/h4>
p>maven deploy命令可以将maven工程部署到webapp下，不过一般用eclipse更将方便。
/p>

2025年maven的使用教程_maven使用教程

maven

maven核心概念

目录结构

POM

坐标

仓库

依赖

生命周期

依赖

相关推荐