# Maven学习笔记
**Repository Path**: zyzdemo/mavenlearningnotes
## Basic Information
- **Project Name**: Maven学习笔记
- **Description**: Maven学习笔记,纯笔记仓库
- **Primary Language**: Unknown
- **License**: GPL-3.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No
## Statistics
- **Stars**: 0
- **Forks**: 0
- **Created**: 2025-07-22
- **Last Updated**: 2025-07-22
## Categories & Tags
**Categories**: Uncategorized
**Tags**: None
## README
- [1.
Maven学习笔记](#1-centermaven学习笔记center)
- [2. 前言](#2-前言)
- [3. 项目构建](#3-项目构建)
- [3.1. idea的项目结构](#31-idea的项目结构)
- [4. Maven概述](#4-maven概述)
- [4.1. Maven安装](#41-maven安装)
- [4.2. Maven的标准目录](#42-maven的标准目录)
- [4.2.1. pom.xml的基本要求](#421-pomxml的基本要求)
- [4.3. Maven生命周期](#43-maven生命周期)
- [4.3.1. 默认的生命周期](#431-默认的生命周期)
- [4.4. Maven常用命令](#44-maven常用命令)
- [4.5. Maven的版本规范](#45-maven的版本规范)
- [4.6. Eclipse配置Maven](#46-eclipse配置maven)
- [4.7. 添加依赖的jar包](#47-添加依赖的jar包)
- [5. Maven依赖](#5-maven依赖)
- [5.1. 依赖范围](#51-依赖范围)
- [5.1.1. classpath](#511-classpath)
- [5.1.2. maven项目](#512-maven项目)
- [5.1.2.1. scope标签](#5121-scope标签)
- [5.1.3. 编译依赖范围(compile)](#513-编译依赖范围compile)
- [5.1.4. 测试依赖范围(test)](#514-测试依赖范围test)
- [5.1.5. 已提供的依赖范围(provided)](#515-已提供的依赖范围provided)
- [5.1.6. 运行时依赖范围(runtime)](#516-运行时依赖范围runtime)
- [5.2. 依赖的传递](#52-依赖的传递)
- [5.2.1. 依赖传递原则](#521-依赖传递原则)
- [5.3. 依赖的排除](#53-依赖的排除)
- [5.4. 聚合工程和继承](#54-聚合工程和继承)
- [6. pom.xml文件](#6-pomxml文件)
- [6.1. 基础配置](#61-基础配置)
- [6.1.1. 典型的pom.xml文件配置](#611-典型的pomxml文件配置)
- [6.2. 构建配置](#62-构建配置)
- [6.3. 仓库配置](#63-仓库配置)
- [6.4. 多环境配置](#64-多环境配置)
- [6.5. 项目信息配置 (了解即可,意义不大)](#65-项目信息配置-了解即可意义不大)
- [7. Maven仓库](#7-maven仓库)
- [7.1. 本地仓库](#71-本地仓库)
- [7.2. 远程仓库](#72-远程仓库)
- [7.2.1. 中央仓库](#721-中央仓库)
- [7.2.1.1. 配置中央仓库镜像](#7211-配置中央仓库镜像)
- [7.3. 私服](#73-私服)
- [7.3.1. Docker构建Nexus私服](#731-docker构建nexus私服)
- [8. Maven插件](#8-maven插件)
- [8.1. Maven-compiler-plugin](#81-maven-compiler-plugin)
- [8.2. jar包插件](#82-jar包插件)
- [9. 聚合工程依赖版本的管理](#9-聚合工程依赖版本的管理)
# 1. Maven学习笔记
# 2. 前言
- 参考资料
https://www.bilibili.com/video/BV1Zo4y1o7Zx?p=13&spm_id_from=pageDriver
# 3. 项目构建
项目构建,就是构建成能够在某一环境中运行的文件。
- **任意给你一套源代码,你如何把它跑起来?**
大概率不能运行。光是几个文件夹和文件,是不能运行的!因为需要和idea或者eclipse打交道,告诉它们如何运行,比如知道main方法在哪里,配置文件在哪里,编译好的文件输出在哪里等等。
- 项目构建中有几个关键点
- jdk啥版本?
- 哪些文件夹是干啥的?源文件?测试文件?配置文件?在哪里?
- 如果是web工程,web.xml放在哪里?
- 编译文件,编译后的文件在哪里?
- 打包,打包成什么文件?
## 3.1. idea的项目结构
平常构建项目时idea或者eclipse已经帮我们做好了
在eclipse中是工作空间和项目的概念,在IDEA中是项目和模块的关系
# 4. Maven概述
## 4.1. Maven安装
- 下载链接: https://maven.apache.org/download.cgi
- 选择版本下载
- windows中选择“apache-maven-3.8.4-bin.zip”版本
- 解压到当前文件夹
- 测试
- 在bin目录下cmd输入命令mvn
>```bash
>D:\program\apache\apache-maven-3.8.4\bin>mvn // 此处需要配置好java环境变量
>--------------------------------------------------
>[INFO] Scanning for projects...
>[INFO] ------------------------------------------------------------------------
>[INFO] BUILD FAILURE
>[INFO] ------------------------------------------------------------------------
>[INFO] Total time: 0.069 s
>[INFO] Finished at: 2021-12-29T17:34:43+08:00
>[INFO] ------------------------------------------------------------------------
>[ERROR] No goals have been specified for this build. You must specify a valid lifecycle phase or a goal in the format : or :[:]:. Available lifecycle phases are: validate, initialize, generate-sources, process-sources, generate-resources, process-resources, compile, process-classes, generate-test-sources, process-test-sources, generate-test-resources, process-test-resources, test-compile, process-test-classes, test, prepare-package, package, pre-integration-test, integration-test, post-integration-test, verify, install, deploy, pre-clean, clean, post-clean, pre-site, site, post-site, site-deploy. -> [Help 1]
>[ERROR]
>[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
>[ERROR] Re-run Maven using the -X switch to enable full debug logging.
>[ERROR]
>[ERROR] For more information about the errors and possible solutions, please read the following articles:
>[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/NoGoalSpecifiedException
>```
- 配置环境变量
- MAVEN_HOME:D:\program\apache\apache-maven-3.8.4
- Path:增加%MAVEN_HOME\bin%
>```bash
>ZHD@LAPTOP-PQIEGIQ8 MINGW64 ~/Desktop
>$ mvn -v // 可以在任何地方运行mvn了
>--------------------------------------
>Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
>Maven home: D:\program\apache\apache-maven-3.8.4
>Java version: 1.8.0_291, vendor: Oracle Corporation, runtime: D:\program\java\jdk\jre
>Default locale: zh_CN, platform encoding: GBK
>OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>```
- 设置配置 (为了自动下载jar包)
- 配置路径。(jar包下载后保存的路径)
- 在MAVEN_HOME/config下更改settings文件
>```xml
>D:/MavenRepository
>```
- 配置阿里云镜像(jar包从哪里下载)
>```xml
>
>
> nexus-aliyun
> *
> Nexus aliyun
> http://maven.aliyun.com/nexus/content/groups/public
>
>
>```
- 配置全局编译jdk版本
>```xml
>
> jdk-1.8
>
> true
> 1.8
>
>
> 1.8
> 1.8
> 1.8
>
>
>```
## 4.2. Maven的标准目录
>```
>src
> |--main
> |--java // 源代码目录
> |--resources // 资源目录
> |--test
> |--java // 测试代码目录
> |--resources // 测试资源目录
> |--target
> |--classes // 编译后的class文件目录
> |-- test-classes //编译后的测试class文件目录
> pom.xml // Maven工程配置文件
>```
这是大部分Maven工程的目录结构,在这个基础上可以合理增删目录
### 4.2.1. pom.xml的基本要求
>```xml
>
> 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">
>
> 4.0.0
> test
> org.xinzhi
> 1.0-SNAPSHOT
>
>
>```
## 4.3. Maven生命周期
Maven生命周期其实就是描述了一个项目从源代码到部署的整个周期
- Maven有三个内置的生命周期:默认(default)、清洁(clean)和站点(site)
- **清洁**(clean)为执行以下工作做必要的清理,就是我们日常做的,删除target文件夹
- **默认**(default)真正进行项目编译打包等工作的阶段
- **站点**(site)生成项目报告、站点、发布站点
### 4.3.1. 默认的生命周期
- **默认**(简化版)
- 验证(validate) - 验证项目是否正确,所有必要的信息可用。
- **编译**(compile) - 编译项目的源代码。
- **测试**(test) - 使用合适的单元测试框架测试编译的源代码。这些测试不应该要求代码被打包或部署。
- **打包**(package)- 采用编译的代码,并以其可分配格式(如JAR)进行打包。
- 验证(verify) - 对集成测试的结果执行任何检查,以确保满足质量标准。
- **安装**(install) - 将软件包安装到本地存储库中,用作本地其他项目的依赖项。
- 部署(deploy) - 在构建环境中完成,将最终的包复制到远程存储库以与其他开发人员和项目共享(私服)。
每一个生命都是一个命令。执行一个命令,这个命令之前的生命周期都会被执行。例如
>```bash
>mvn install
>```
会执行按顺序执行安装之前的所有生命周期:验证、编译、打包等)
## 4.4. Maven常用命令
|命令| 说明|
|:-:|:-:|
|mvn –version| 显示版本信息|
|mvn clean| 清理项目生产的临时文件,一般是模块下的target目录|
|mvn compile| 编译源代码,一般编译模块下的src/main/java目录|
|mvn package| 项目打包工具,会在模块下的target目录生成jar或war等文件|
|mvn test| 测试命令,或执行src/test/java/下junit的测试用例|
|mvn install| 将打包的jar/war文件复制到你的**本地Maven仓库**中,供其他模块使用|
|mvn deploy |将打包的文件发布到远程仓库,提供其他人员进行下载依赖|
|mvn site| 生成项目相关信息的网站|
|mvn dependency:tree |打印出项目的整个依赖树|
|mvn archetype:generate |创建Maven的普通java项目|
|mvn tomcat:run |在tomcat容器中运行web应用|
## 4.5. Maven的版本规范
所有的软件都有版本
Maven中使用如下几个要素来定位一个项目,因此它们又称为项目的坐标
- **groupId**:团体、组织的标识符。(表示这个项目是由哪个团队开发的)
- 团体标识的约定是,它以创建这个项目的组织名称的逆向域名开头,一般对应着Java的包的结构,例如org.apache
- **artifactId**:单独项目的唯一标识符。(就是我们项目的名字)
- 比如我们的tomcat, commons等。不要在artifactId中包含点号(.)。
- **version**:项目的版本。
- **packaging**:项目的类型,默认是jar,描述了项目打包后的输出。类型为jar的项目产生一个JAR文件,类型为war的项目产生一个web应用
Maven在版本管理时候可以使用几个特殊的字符串 SNAPSHOT,LATEST,RELEASE。比如"1.0-SNAPSHOT"。各个部分的含义和处理逻辑如下说明
- **SNAPSHOT**:这个版本一般用于开发过程中,表示不稳定的版本。
- **LATEST**:指某个特定构件的最新发布,这个发布可能是一个发布版,也可能是一个 snapshot版,具体看哪个时间最后。
- **RELEASE**:指最后一个发布版
## 4.6. Eclipse配置Maven
- 参考资料
https://blog.csdn.net/wcc27857285/article/details/81812304
- 在eclipse中使用maven进行编译
https://blog.csdn.net/vah101/article/details/24660795/
## 4.7. 添加依赖的jar包
在pom.xml中添加类似如下的代码
>```xml
>
>
> junit
> junit
> 4.7
> test
>
>
>```
# 5. Maven依赖
如果需要一个jar包,maven会先从本地的maven仓库中查找,如果没查到则会从远程maven仓库寻找(有私立服务器则先从私立服务器中查找)。
## 5.1. 依赖范围
### 5.1.1. classpath
顾名思义,classpath就是编译后的class所在的路径。事实上我们的类加载器(classloader)就是从classpath中加载class的二进制文件
### 5.1.2. maven项目
maven工程会将src/main/java 和 src/main/resources 文件夹下的文件全部打包在classpath中。运行时他们两个的文件夹下的文件会被放在一个文件夹下。
maven 项目**不同的阶段**引入到classpath中的依赖是**不同**的,例如:
- 编译时,maven 会将与编译相关的依赖引入classpath中
- 测试时,maven会将测试相关的的依赖引入到classpath中
- 运行时,maven会将与运行相关的依赖引入classpath中
#### 5.1.2.1. scope标签
- **scpoe标签就是依赖范围的配置**
该项默认配置compile,可选配置还有test、provided、runtime、import
**其中compile、test和provided用的较多**。
- web项目有些jar包(例如selvlet-api)运行时其实是不需要的,因为tomcat中有,但是编译时需要,因为编译时没有tomcat环境。
- 有些jar包只有在测试时需要(例如JUnit),真实运行时不需要。
- 有些jar运行、测试时必须要有,编译时不需要,例如jdbc驱动,编译时用的都是jdk中的接口,运行时我们才使用反射注册驱动。
### 5.1.3. 编译依赖范围(compile)
**该范围就是默认依赖范围**,此依赖范围对于 **编译、测试、运行** 三种classpath都有效,举个简单的例子,假如项目中有fastjson的依赖,那么fastjson不管是在编译,测试,还是运行都会被用到,因此fastjson必须是编译范围(构件默认的是编译范围,所以依赖范围是编译范围的无须显示指定)
>```xml
>
>
> fastjson
> fastjson
> 1.2.68
> compile // 这里填写的就是依赖范围
>
>
>```
### 5.1.4. 测试依赖范围(test)
使用此依赖范围的依赖,只对 **测试** classpath有效,在编译主代码和项目运行时,都将无法使用该依赖
>```xml
>
>
> junit
> junit
> 4.7
> test
>
>
>```
### 5.1.5. 已提供的依赖范围(provided)
使用该依赖范围的maven依赖,只对 **编译和测试** 的classpath有效,对运行的classpath无效,典型的例子就是servlet-api, 编译和测试该项目的时候需要该依赖,但是在运行时,web容器已经提供的该依赖,所以运行时就不再需要此依赖,如果不显示指定该依赖范围,并且容器依赖的版本和maven依赖的版本不一致的话,可能会引起版本冲突,造成不良影响。
>```xml
>
> javax.servlet
> javax.servlet-api
> 4.0.1
> provided
>
>```
### 5.1.6. 运行时依赖范围(runtime)
使用该依赖范围的maven依赖,只对 **测试和运行** 的classpath有效,对编译的classpath无效,典型例子就是JDBC的驱动实现,项目主代码编译的时候只需要JDK提供的JDBC接口,只有在测试和运行的时候才需要实现上述接口的具体JDBC驱动。
>```xml
>
> mysql
> mysql-connector-java
> 5.1.25
> runtime
>
>```
## 5.2. 依赖的传递
jar其实也是别人写的jar包,它也会依赖其他的jar包,传递性能让我们可以不用关心我们所依赖的jar包依赖了哪些jar包,只要我们添加该依赖,它会自动引入所依赖的jar包。(就像python中安装tensorflow时它会自动安装numpy)
### 5.2.1. 依赖传递原则
- **最短路径传递原则**
- 如果A依赖于B,B依赖于C,在B和C 中同时有log4j的依赖,并且这两个版本不一致,那么A会根据 **最短路径** 原则,在A中会传递过来B的log4j版本
```mermaid
graph RL
id4["C.jar"]-->id3["B.jar
此jar依赖C.jar和D.jar"]-->id2["A.jar
此jar依赖B.jar和D.jar"]-->id1["我们工程依赖A.jar"]
id5("D.jar")-->|"两步"|id2
id6["D.jar"]-->|"三步"|id3
```
- **路径相同先声明原则**
- 如果我们的工程同时依赖于B和A,B和C没有依赖关系,并且都有D的依赖,且版本不一致,那么会引入在pom.xml中先声明依赖的log4j版本。
```mermaid
graph RL
id3["B.jar
此jar依赖C.jar和D.jar"]-->id1["我们工程依赖A.jar、B.jar"]
id2["A.jar
此jar依赖B.jar和D.jar"]-->id1
id4("D.jar 1.2.3")-->|"两步"|id3
id5("D.jar 1.3.2")-->|"两步"|id2
```
因为A依赖于B,所以要有B才能有A,B先于A被声明,故B中的D.jar先被声明。因为1.2.3版本先被声明,因此会引用1.2.3的版本。
## 5.3. 依赖的排除
上述案例中,不同版本的jar选一个会导致一个问题,1.3.2版本高,A.jar可能用到了高版本的一些新的方法,此时因为某些原因系统选择了低版本,就会导致A.jar报错,无法运行。那么就要想办法把低版本排除掉,一般高版本会兼容低版本。
- 结合上个例子,我们想把低版本的D.jar排除了,就可以这样做,这样系统就只能依赖高版本
>```xml
>
>
> com.xinzi
> B
> 1.5.3
> // 排除掉相关的依赖
>
> com.xinzhi
> D
>
>
>
>
> com.xinzhi
> A
> 1.12.2
>
>
>```
## 5.4. 聚合工程和继承
聚合和继承,在分布式开发中必须要用的
比如在idea中,我们**可以在一个项目工程中,再建一个子项目工程**,这种工程套工程的方式就叫**聚合**
- Eclipse中创建聚合工程详见链接 https://blog.csdn.net/vistaed/article/details/106647543
- 要点:
- 父工程为 Maven Project , packaging 模式为 POM
- 子工程为 Maven Module , packaging 模式为 jar
- 聚合模块(父模块)的打包方式必须为 **pom**,否则无法完成构建。
- 在聚合多个项目时,如果这些被聚合的项目中需要引入**相同的Jar**,那么可以将这些Jar写入**父pom**中,各个子项目继承该pom即可。,父模块的打包方式必须为pom,否则无法构建项目
- 父工程中的依赖,在子工程中可以直接使用
- 子工程之前也可以相互引用
- 子模块中的 pom.xml 文件
>```xml
>
> parent
> org.example
> 1.0-SNAPSHOT
>
>4.0.0
>
>childern-two
>```
可以被继承的POM元素如下:
- groupId:项目组ID,项目坐标的核心元素
- version:项目版本,项目坐标的核心因素
- properties:自定义的Maven属性 一般用于同一制定各个依赖的版本号
- dependencies:项目的依赖配置 公共的依赖
- dependencyManagement:项目的依赖管理配置
- repositories:项目的仓库配置
- build:包括项目的源码目录配置、输出目录配置、插件配置、插件管理配置等
- **一些对项目的描述**
- description:项目的描述信息
- organization:项目的组织信息
- inceptionYear:项目的创始年份
- url:项目的URL地址
- developers:项目的开发者信息
- contributors:项目的贡献者信息
- distributionManagement:项目的部署配置
- issueManagement:项目的缺陷跟踪系统信息
- ciManagement:项目的持续集成系统信息
- scm:项目的版本控制系统
- malilingLists:项目的邮件列表信息
- reporting:包括项目的报告输出目录配置、报告插件配置等
# 6. pom.xml文件
## 6.1. 基础配置
### 6.1.1. 典型的pom.xml文件配置
>```xml
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0http://maven.apache.org/xsd/maven-4.0.0.xsd">
>
>
> 4.0.0
>
> com.xinzhi
>
> test
>
> 1.0.0-SNAPSHOT
>
>
> jar
>
>
>
> //定义变量
> UTF-8
> 1.8
> 1.8
> 4.12 // 依赖可以不加版本号,不加则默认下载最新版本
>
>
>
>
>
>
>
>
>
> junit
> junit
> ${junit.version} // 引用上面定义的junit的版本
>
>
> complie
>
> false
>
>
>
>
> org.slf4j
> slf4j-api
>
>
>
>
>
> ...
>
>```
## 6.2. 构建配置
构建配置可以不写,因为基本所有地方都有默认值。这些东西其实没有必要重新配置。
>```xml
>
>
>
> ${basedir}\src\main\java
>
>
>
> ${basedir}\target\classes
>
>
> ${basedir}\target\test-classes
>
>
>
>
>
> src/main/java
>
> **/*.properties
> **/*.xml
>
> false
>
>
> src/main/resources
>
> **/*.properties
> **/*.xml
>
> false
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ...具体在插件使用中了解
>
>
>
>
>
>
>
> ...
>
>
>
>```
## 6.3. 仓库配置
>```xml
>
>
> alimaven
> aliyun maven
> http://maven.aliyun.com/nexus/content/groups/public/
>
> true //稳定版的软件下载
>
>
> false //快照版的软件不进行下载
>
>
>
>```
- settings.xml中配置的是镜像仓库
- pom.xml里面的仓库与setting.xml里的仓库功能是一样的。主要的区别在于,pom里的仓库是个性化的。比如一家大公司里的setting文件是公用的,所有项目都用一个setting文件,但各个子项目却会引用不同的第三方库,所以就需要在pom.xml里设置自己需要的仓库地址。
## 6.4. 多环境配置
简单来说就是,开发环境、测试环境、运行环境(生产环境)等各个环境都进行环境的配置。在\\中进行配置,\\之间可以配置任何东西。
>```xml
>
>
> dev
>
> dev
>
>
>
> ali
> ali repo
> https://maven.aliyun.com/repository/central
>
> true
>
>
> true
>
>
>
>
>
> test
>
> test
>
>
>
> ali
> ali repo
> https://mirrors.huaweicloud.com/repository/maven/
>
> true
>
>
> true
>
>
>
>
>
>
> true
>
> pro
>
> pro
>
>
>
>```
需要用到哪个环境,只需要把\\移到对应的\\中即可
>```xml
>
>
> true //默认激活
>
> pro // 默认生产环境
>
> pro
>
>
>```
## 6.5. 项目信息配置 (了解即可,意义不大)
>```xml
>
>banseon-maven
>
>
>http://www.clf.com/
>
>
>
>
>A maven project to study maven.
>
>
>
>
>
>
>
>
>
>
>
> HELLO WORLD
>
> banseon
>
> banseon@126.com
>
>
>
>
> Project Manager
> Architect
>
>
> demo
>
> http://hi.clf.com/
>
>
> No
>
>
> -5
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Apache 2
>
> http://www.clf.com/LICENSE-2.0.txt
>
> repo
>
> Abusiness-friendly OSS license
>
>
>
>
>
>
>...还有很多
>```
# 7. Maven仓库
- Maven仓库分类
- 本地仓库
- 私有服务器(自己公司搭建的)
- 其他公共库
- maven项目使用的仓库一共有如下几种方式:
- 中央仓库,这是默认的仓库
- 镜像仓库,通过 sttings.xml 中的 settings.mirrors.mirror 配置 (镜像是拦截对中央仓库的请求)
- 全局profile仓库(全局的多环境配置),通过 settings.xml 中的 settings.repositories.repository 配置
- 项目仓库,通过 pom.xml 中的 project.repositories.repository 配置
- pom.xml的配置只服务于当前的项目
- settings.xml服务于全局
- 项目profile仓库,通过 pom.xml 中的 project.profiles.profile.repositories.repository 配置
- 本地仓库
- 仓库的搜索顺序
>```
>local_repo > settings_profile_repo > pom_profile_repo > pom_repositories > settings_mirror > central
>```
## 7.1. 本地仓库
本地仓库是Maven在本地存储构建的地方。Maven的本地仓库,在安装maven后并不会创建,它是在第一次执行Maven命令的时候才被创建。
Maven本地仓库的默认位置:无论是Windows还是Linux,在用户的目录下都有一个.m2/repository/的仓库目录,这就是Maven仓库的默认位置。
在Maven的目录下的conf目录下,有一个settings.xml文件,是Maven的配置文件,在里面可以修改本地仓库的位置。
>```xml
>
>D:/myworkspace/maven_repository
>```
## 7.2. 远程仓库
### 7.2.1. 中央仓库
中央仓库是默认的的远程仓库,Maven在安装的时候,自带的就是中央仓库的配置。
所有的Maven都会继承超级POM,超级POM种包含如下配置
>```xml
>
>
> central
> Cntral Repository
> http://repo.maven.apache.org
> default
>
> false
>
>
>
>```
#### 7.2.1.1. 配置中央仓库镜像
- 还可以在里面配置优先使用的镜像,比如在国内直接连中央仓库速度较慢,一般使用阿里的镜像仓库。
>```xml
>
>
>
>
> alimaven
>
> central
> aliyun maven
> http://maven.aliyun.com/nexus/content/groups/public/
>
>
>```
## 7.3. 私服
私服是一种特殊的远程仓库,它是架设在局域网内的仓库服务,**私服代理广域网上的远程仓库**,供局域网内的Maven用户使用,当Maven需要下载构件的时候,它从私服请求,如果私服上不存在该构件,则从外部的仓库下载,缓存在私服上之后,再为Naven的下载请求提供服务。
- Maven私服的特点
- 加速构建
- 节省带宽
- 稳定
- 可以建立本地内部仓库
- 可以建立公共仓库
### 7.3.1. Docker构建Nexus私服
一般来说,Nexus的仓库分为以下几类:
- hosted 宿主仓库:主要用于部署无法从公共仓库获取的构件(例如oracle的JDBC)以及自己或第三方的项目构件
- proxy 代理仓库:代理公共的远程仓库
- group 仓库组:Nexus通过仓库组的概念统一管理多个仓库,这样我们在项目中直接请求仓库组即可请求到仓库组管理的多个仓库
(待补充,等日后自己搭建私服的时候再来补充)
- 参考资料
https://ydlclass.com/doc21xnv/frame/maven/#_2%E3%80%81%E8%BF%9C%E7%A8%8B%E4%BB%93%E5%BA%93
# 8. Maven插件
Maven实际上是基于插件编译的插件。每个任务实际上是由插件完成。Maven 插件通常被用来:
- 打包jar 文件
- 创建 war 文件
- 编译代码文件
- 代码单元测试
- 创建工程文档
- 创建工程报告
插件通常提供了一个目标的集合,执行的语法如下
>```
>mvn [plugin-name]:[goal-name]
>```
例如,一个 Java 工程可以使用 maven-compiler-plugin 的 compile-goal 编译,使用以下命令:
>```
>mvn compiler:compile
>```
当使用第三方的插件时,需要如上执行。
## 8.1. Maven-compiler-plugin
设置maven编译的jdk版本,maven3默认用jdk1.5,maven2默认用jdk1.3
>```xml
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.1
>
> 1.8
> 1.8
> UTF-8
>
>
>```
**以后所有的工程,必须加上这段代码。** 只要写项目,必须要有这个配置。
## 8.2. jar包插件
- maven-jar-plugin,默认的打包插件,用来打普通的project JAR包;
- maven-shade-plugin,用来打可执行JAR包,也就是所谓的fat JAR包;
- maven-assembly-plugin,支持自定义的打包结构,也可以定制依赖项等。
我们日常使用的以maven-assembly-plugin为最多,因为**大数据项目**中往往有很多shell脚本、SQL脚本、.properties及.xml配置项等,采用assembly插件可以让输出的结构清晰而标准化。
>```xml
>
> org.apache.maven.plugins
> maven-assembly-plugin
> 3.3.0
>
>
> make-assembly
>
> package
>
>
> single
>
>
>
>
>
>
> true
> com.xinzi.Test
>
>
>
>
> jar-with-dependencies
>
>
>
>```
以后遇到这种,直接复制之后来改就行了
# 9. 聚合工程依赖版本的管理
在聚合工程中,子工程会继承父工程中的依赖,如果不加管理,则子工程在打包时会自动打包,但是子工程有时候根本用不到父工程中的依赖,也被打包进来就显得很不合理。这时候就需要用到 \ \来管理。
- 在**父工程**中改写如下
>```xml
>
>
>
> commons-lang
> commons-lang
> 2.1
>
>
>
>```
- 可以进一步改进父工程中依赖的配置。具体如下:
>```xml
>
> 2.1 // 以后改就在这里改就行了。(例如有100个依赖,则这样比较方便)
>
>
>
>
>
> commons-lang
> commons-lang
> ${commons-lang.version}
>
>
>
>```
- 父工程做的只是“版本管理”,让所有的工程使用的jar包的版本保持一致。
- 父工程不直接添加依赖,只做统一的版本控制
- 如果需要该jar包,则在**子工程中再次进行依赖**。(在子工程中就不需要写明版本了,因为父工程中有了)
>```xml
>
>
> commons-lang
> commons-lang
>
>
>```