0%

Maven汇总

Basic Knowledge

Maven常用命令

scope详解

https://www.cnblogs.com/hzzll/p/6738955.html

dependencies与dependencyManagement的区别

根据maven子模块继承父模块的特性,不难理解两者肯定都有继承父模块依赖的作用,但是要注意他们的区别是:

dependencies里面声明的依赖,子模块会默认全部继承,不用手动去引入依赖;而dependencyManagement里面声明的依赖,则不会再子模块中自动去隐式依赖,只有子模块中声明了依赖,并且没有指明依赖的版本这种情况才会到父模块中寻找dependencyManagement中的对应依赖,要注意的是,如果子模块声明了依赖版本号,那么在dependencyManagement中如果也有同一依赖库的不同版本共存的话,maven优先去依赖的是子模块自己的版本

Maven仓库下载依赖太慢的解决方案

将仓库中心更改为阿里云的,修改setting.xml,如下:

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
<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
<mirrors>
<!-- 阿里云仓库 -->
<mirror>
<id>alimaven</id>
<mirrorOf>central</mirrorOf>
<name>aliyun maven</name>
<url>http://maven.aliyun.com/nexus/content/repositories/central/</url>
</mirror>

<!-- 中央仓库1 -->
<mirror>
<id>repo1</id>
<mirrorOf>central</mirrorOf>
<name>Human Readable Name for this Mirror.</name>
<url>http://repo1.maven.org/maven2/</url>
</mirror>

<!-- 中央仓库2 -->
<mirror>
<id>repo2</id>
<mirrorOf>central</mirrorOf>
<name>Human Readable Name for this Mirror.</name>
<url>http://repo2.maven.org/maven2/</url>
</mirror>
</mirrors>
</settings>

Maven BOM

BOM stands for Bill Of Materials. A BOM is a special kind of POM that is used to control the versions of a project’s dependencies and provide a central place to define and update those versions.
BOM字面理解是”材料清单”,它是一种特别的POM,可以用来控制项目的多个依赖,相当于某个依赖集群的中心控制处。

Transitive Dependencies 依赖传递性

Maven can discover the libraries that are needed by our own dependencies in our pom.xml and includes them automatically. There’s no limit to the number of dependency levels that the libraries are gathered from.
Maven通过pom.xml的多层级依赖是没有限制的,也就是,父模块可以递归依赖子模块的任何依赖,所以可能会出现如下的矛盾:

A -> B -> C -> D 1.4 and A -> E -> D 1.0

那么Maven给出了两个解决方案:

  1. We can always guarantee a version by declaring it explicitly in our project’s POM. For instance, to guarantee that D 1.4 is used, we should add it explicitly as a dependency in the pom.xml file. 通过在A的pom.xml明确声明D的依赖版本,这样子就不会采用子模块传递过来的依赖了。
  2. We can use the Dependency Management section to control artifact versions. 可以通过依赖管理来控制依赖版本,也就是直接继承父模块,通过;或者通过import BOM。
    1
    2
    3
    4
    5
    <parent>
    <groupId>baeldung</groupId>
    <artifactId>Baeldung-BOM</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    </parent>
1
2
3
4
5
6
7
8
9
10
11
<dependencyManagement>
<dependencies>
<dependency>
<groupId>baeldung</groupId>
<artifactId>Baeldung-BOM</artifactId>
<version>0.0.1-SNAPSHOT</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>

maven依赖版本的优先权如下:
1、项目自己pom.xml里面直接声明的版本
2、从parent项目继承的版本
3、通过import形式的依赖版本,和import的顺序有关,先import进来的版本被优先采用。

详情参考:https://www.baeldung.com/spring-maven-bom#2-what-is-maven-bom

mvn compile与mvn install、mvn deploy的区别

  • mvn compile,编译类文件
  • mvn install,包含mvn compile,mvn package,然后上传到本地仓库
  • mvn deploy,包含mvn install,然后,上传到私服

maven-compiler-plugin 插件

可以用于指定模块编译的jdk版本

1
2
3
4
5
6
7
8
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<target>${java.version}</target>
<source>${java.version}</source>
<encoding>UTF-8</encoding>
</configuration>
</plugin>

Maven中-DskipTests和-Dmaven.test.skip=true的区别

在使用mvn package进行编译、打包时,Maven会执行src/test/java中的JUnit测试用例,有时为了跳过测试,会使用参数-DskipTests和-Dmaven.test.skip=true,这两个参数的主要区别是:
-DskipTests,不执行测试用例,但编译测试用例类生成相应的class文件至target/test-classes下。
-Dmaven.test.skip=true,不执行测试用例,也不编译测试用例类。

profile切换正式环境和测试环境

可以使用通过id标签来切换不同环境的依赖

mvn install执行要注意的地方 (错误笔记*)

通过在父项目的pom.xml目录执行mvn install可以连同子模块也一起安装,然后假如有多层级的父子模块依赖的情况下,mvn install是不会递归去安装子模块的子模块的。
比如,parent模块(BOM)下有subParent(BOM),subParent下面的子模块(jar),这个时候再parent模块下执行mvn install,subParent的jar是不会安装的,需要到subParent执行一次

Maven整个声明周期

验证(validate) 验证项目是正确的,所有必要的信息可用。
初始化(initialize) 初始化构建状态,例如设置属性或创建目录。
产生来源(generate-sources) 生成包含在编译中的任何源代码。
流程源(process-sources) 处理源代码,例如过滤任何值。
生成资源(generate-resources) 生成包含在包中的资源。
流程资源(process-resources) 将资源复制并处理到目标目录中,准备打包。
编译(compile) 编译项目的源代码。
工艺类(process-classes) 从编译后处理生成的文件,例如对Java类进行字节码增强。
生成测试来源(generate-test-sources) 生成包含在编译中的任何测试源代码。
流程测试来源(process-test-sources) 处理测试源代码,例如过滤任何值。
生成测试资源(generate-test-resources) 创建测试资源。
流程测试资源(process-test-resources) 将资源复制并处理到测试目标目录中。
测试编译(test-compile) 将测试源代码编译到测试目标目录中
流程检验类(process-test-classes) 从测试编译中处理生成的文件,例如对Java类进行字节码增强。对于Maven 2.0.5及以上版本。
测试(test) 使用合适的单元测试框架运行测试。这些测试不应该要求代码被打包或部署。
制备包(prepare-package) 在实际包装之前,执行必要的准备包装的操作。这通常会导致打包的处理版本的包。(Maven 2.1及以上)
打包(package) 采取编译的代码,并以其可分发的格式(如JAR)进行打包。
预集成测试(pre-integration-test) 在执行集成测试之前执行所需的操作。这可能涉及诸如设置所需环境等。
集成测试(integration-test) 如果需要,可以将该包过程并部署到可以运行集成测试的环境中。
整合后的测试(post-integration-test) 执行集成测试后执行所需的操作。这可能包括清理环境。
校验(verify) 运行任何检查以验证包装是否有效并符合质量标准。
安装(install) 将软件包安装到本地存储库中,以作为本地其他项目的依赖关系。
部署(deploy) 在集成或发布环境中完成,将最终软件包复制到远程存储库,以与其他开发人员和项目共享。
————————————————
版权声明:本文为CSDN博主「zhangxitab」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/zhangxitab/article/details/91047445

-pl -am -amd

参考

Problem Solution

记录一个Idea中Maven的奇葩错误

因为我从SVN拉代码下来是将项目根目录的名字修改为其他,导致根目录的pom.xml里面的name标签的值和文件不匹配,idea就一直报红,无法依赖其他依赖。。

新增加properties的变量时,编译打包报错

很有可能需要把子模块modules都注释掉,然后编译一个或者多个父模块之后再放开子模块的注释。

jar.original

  • jar.original 是普通jar包,不包含依赖
  • .jar 是可执行jar包,包含了pom中的所有依赖,可以直接用java -jar 命令执行
  • 如果是部署,就用.jar
  • 如果是给别的项目用,就要给.jar.original这个包