Maven知识点总结

最新推荐文章于 2024-07-02 10:40:11 发布

爱喝咖啡的程序员

最新推荐文章于 2024-07-02 10:40:11 发布

阅读量419

点赞数

本文链接：https://blog.csdn.net/miaomiao19971215/article/details/104129718

版权

一. 概念

Maven是一个用于项目构建和管理Jar包依赖的工具。

二. Maven的优势

1. 项目构建。Maven整合了从清理、编译、测试到生成报告，再到打包和部署的全套自动化构建过程。

2. Jar管理。通过Maven的坐标系统，在仓库中能轻松的定位到任何一个java类库，我们可以借助它来有序的管理复杂的jar依赖。

三. Maven与Gradle的区别

1. 多模块构建

在现在的项目中，我们往往会将项目拆分成多个模块，在Maven中需要定义一个parent的pom.xml作为一组module的通用配置，子模块通过<module>进行定义。在gradle中也支持多模块构建，build.gradle中可以通过subproject或allproject来对子模块进行一些依赖上的定义，针对子模块的声明则在settings.gradle中通过include语句来实现。

2. 依赖管理系统

在Maven中通过GroupId,ArtifactId以及Version组成一个唯一的标识，而Gradle支持动态的版本依赖，在版本号后使用+号就可以实现动态的版本管理。

3. 一致的构建模型

Maven设置了标准的项目周期，包含验证、初始化、生成原始数据、处理原始数据、生成资源、处理资源、编译、处理类等等。而Gradle更加的灵活，可以创建一个task，随时通过depends建立与已有的task的依赖关系。

4. 一致的项目结构

Maven中指定了一套标准的项目结构作为java项目结构(src/main/java,src/main/resource,src/test/java,src/test/resource)， Gradle也使用了这套标准。在Gradle中只需要在文件中包含applyplugin:'java'，系统即可自动识别。

5. 插件机制

两者都采用了插件机制。

四. Maven基本命令

1. mvn clean: 清理。将根目录下的target目录清理掉。

2. mvn compile: 编译。将项目中的.java文件编译成.class文件。

3. mvn test: 测试。执行项目src/test/java路径下的单元测试类。

4. mvn package: 打包。将项目打包并放置在项目根目录的.target目录下。

5. mvn install: 把项目安装至本地仓库。

6. mvn deploy: 将项目部署到私服环境中。

7. mvn package -DskipTests: 打包并跳过测试。

8. mvn denpendency:tree: 查看依赖的树形结构，用于排除依赖冲突。

9. mvn install:install-file -Dfile=Jar包的完整路径 -DgroupId=自定义groupId -DartifactId=自定义artifactId -Dversion=自定义 version -Dpackaging=jar 将现有的jar包打包(上传)至本地仓库

10.mvn deploy:deploy-file -Dfile=Jar包的完成路径 -DgroupId=自定义groupId -DartifactId=自定义artifactId -Dversion=自定义 version -Dpackaging=jar -Durl=http://ip:port/nexus/content/repositories/thirdparty/ -DrepositoryId=thirdparty 将本地已有的jar打包(上传)至私服

五. Maven的特性

5.1 依赖管理

1. 坐标

以下是坐标相关的属性:

1. groupId: 项目所属组织的唯一标识，一般由域和公司名称组成

2. artifactId: 项目名称

3. version: 项目当前所处的版本号

4. packaging: 项目的打包方式，默认为jar

5. classifier: 用于指明同一个pom的不同构件。比如针对相同groupId,artifactId,version，可以通过指定不同的JDK版本或者组成部分(如源代码source，文档doc，类文件等)，以此来获取不同的构件。

2. 依赖范围scope

Maven在编译主代码时，需要使用一套classpath，测试代码时需要使用另一套classpath，运行代码时也会使用一套独立的 classpath。依赖范围就是用来控制依赖与这三种classpath。maven有以下几种依赖范围:

1. compile: 编译依赖范围，默认使用该依赖范围。对编译、测试和运行时使用的三类classpath都有效。

2. test: 测试依赖范围。只对测试的classpath有效，只在编译测试代码和运行测试单元时有效。

3. provided: 已提供依赖的范围。在编译和测试的classpath中都有效，但在运行时无效。

4. runtime: 运行时依赖。在测试和运行时有效，但在编译时无效。

5. system: 系统依赖范围。与provided的依赖范围完全一致，必须通过systemPath元素显示的指定依赖文件的路径。

6. import: 导入依赖范围。不对上述三种classpath产生任何影响。

3. 依赖的传递性

比如A依赖了B，B又依赖了C，则把B称作A的第一依赖，C称作A的第二依赖，C之所以能够被A依赖，是因为借助了依赖的传递性。如下图所示，最左边一列表示第一直接依赖范围，最上方一行表示第二直接依赖范围。

注意: 当第一依赖是compile，第二依赖是runtime时，根据依赖的传递性，传递依赖的范围是runtime。因为C在B中时就没参与项目的编译，况且A使用的是B，所以C没有必要支持A项目的编译。

	compile	test	provided	runtime
compile	compile	--	--	runtime
test	test	--	--	test
provided	provided	--	provided	provided
runtime	runtime	--	--	runtime

4. 依赖调解

项目A有这样的依赖关系: A->B->C->X(1.0)，A->D->X(2.0)，那么在项目A中，哪个版本的X会被Maven解析使用呢？

Maven依赖调解的第一原则: 路径最近者优先。因此上述问题中，X(2.0)将会被解析。

若依赖路径的长度相同，比如A->C->X(1.0)，A->D->X(2.0)，依赖的长度相同，那么Maven会如何解析呢？

Maven依赖调解的第二原则: 第一声明者优先。上述问题中，如果C的依赖声明在D之前，则X(1.0)将会被解析。

5. 可选依赖

被 <optional>true</optional> 所修饰的依赖就是可选依赖。它们只对当前项目产生影响，不会被传递。

6. 排除依赖

依赖的传递性会为项目隐式的引入了许多依赖，虽然极大的简化了依赖管理，但有时候并非所有的依赖在当前项目中都被需要，此时我们就可以对传递而来的依赖进行排除。做法如下:

5.2 生命周期

1. validate: 验证工程(项目)是否正确，所有的资源是否可用。

2. compile: 编译项目的源代码。

3. test: 使用合适的单元测试框架来已编译的源代码。测试时无需对项目进行打包和部署。

4. package: 把已编译的代码打包成可以发布的格式，具体格式参考pom.xml文件中的packaging元素的值，默认打包成Jar。

5. verify: 运行所有检查，验证包是否有效且达到了质量标准。

6. install: 把包安装到Maven的本地仓库中，可以被本地其他工程作为依赖来使用。

7.deploy: 在集成或发布环境下执行。将最终版本的包上传至远程私服的仓库中，供其他开发者的其他工程使用。

5.3 仓库

Maven仓库分为本地仓库和远程仓库，而远程仓库又可以被分成中央仓库、私服以及其他公共库。

Maven中任何一个依赖、插件或者项目构建的输出，都可以被称为构件。任何一个构件都会有唯一的坐标，根据坐标可以定义其在仓库中的唯一存储路径。Maven仓库是基于简单文件系统存储的。

1. 本地仓库

可以在Maven的配置文件settings.xml中进行如下配置:

<localRepository>本地仓库的绝对路径地址</localRepository>

2. 远程仓库

当在本地仓库内搜索不到依赖时，就需要访问远程仓库。远程仓库可以配置在某一个需要项目的pom.xml文件中，也可以配置在全局的settings.xml中。

1. 在项目的pom.xml内配置远程仓库地址

<repositories>  
        <repository>  
            <id>jboss</id>  
            <name>JBoss Repository</name>  
            <url>http://repository.jboss.com/maven2/</url>  
            <releases>  
                <!-- Maven从远程仓库检查更新的频率（比较本地pom和远程pom的时间戳） 
                     daily:每天都检查一次(默认) never:从不检查 
                     always: 每次构件都检查更新 interval n:每隔n分钟检查一次-->
                <updatePolicy>daily</updatePolicy><!-- never,always,interval n -->  
                <enabled>true</enabled>  
                <!-- maven检查和检验文件的策略，warn为默认值，还可以选择ignore和fail，
                表示当maven检查检验和文件失败之后应该采取的行动 -->
                <checksumPolicy>warn</checksumPolicy><!-- fail,ignore -->  
            </releases>  
            <snapshots>  
                <!-- 是否从该仓库中获取不稳定的SNAPSHOT版本的构件 -->
                <enabled>false</enabled>  
            </snapshots>  
            <layout>default</layout>  
        </repository>  
</repositories>

出于安全考虑，访问某些仓库时需要验证身份，而鉴权相关的代码只能在settings.xml中编写。我们可以打开 settings.xml，找到<servers></servers>标签，用以下方式书写鉴权代码:

<servers>
<server>
      <id>company-snapshots</id>
      <username>admin</username>
      <password>123456</password>
<server>
</servers>

2. 在Maven的配置文件settings.xml中配置全局的远程仓库地址(所有项目共享)

打开settings.xml，找到<profiles></profiles>标签，接着就可以书写<repositories>了，方法与在项目的pom.xml中一样。

3. 私服

私服是一种特殊的远程仓库，为了节省网络带宽和构件的下载时间，有条件的情况下，建议在局域网内架设一个，通过私服来代理所有的远程仓库。

4. 中央仓库

Maven本身已经为我们配置好了中央仓库的地址，具体位置在$MAVEN_HOME/lib/maven-model-builder-3.6.3.jar，解压或直接反编译jar包，打开org.apache.maven.model包下的pom-4.0.0.xml，可以看到如下语句:

  <repositories>
    <repository>
      <id>central</id>
      <name>Central Repository</name>
      <url>https://repo.maven.apache.org/maven2</url>
      <layout>default</layout>
      <snapshots>
        <enabled>false</enabled>
      </snapshots>
    </repository>
  </repositories>

其中，https://repo.maven.apache.org/maven2就是中央仓库的远程访问地址。

5. settings.xml文件的配置说明

1. 声明规范

xmlns用于声明命名空间，这就意味着，在<settings>标签内的元素都必须遵守命名空间给出的规范。

<?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">

2. localRepository

定义在settings标签内部。指明了本地仓库的物理路径。默认值为${user.home}/ .m2/repository

<localRepository>/Users/jack/repo</localRepository>

3. interactiveMode

定义在settings标签内部。maven是否需要和用户交互(一串提示)，以便获得输入。默认值为false。

<interactiveMode>true</interactiveMode>

4. usePluginRegistry

maven是否需要使用plugin-registry.xml来管理插件版本。若需要让maven使用${user.home}/ .m2/plugin-registry.xml来管理版本插件，则设置为true，默认值为false。

<usePluginRegistry>false</usePluginRegistry>

5. offline

maven是否需要在离线模式下运行。如果构件系统需要在离线模式下运行，则设置为true，否则设置为false。比如由于网络原因或者安全因素，构件服务器无法连接远程仓库时，就可以使用这个属性。默认为false。

<offline>false</offline>

6. pluginGroups

https://www.cnblogs.com/yangxia-test/p/4409736.html

5.4 pom.xml 配置

5.5 plugins打包插件

1. maven-shade-plugin

2. maven-dependency-plugin

3. maven-assembly-plugin

5.6 常见内置变量

${basedir} 项目根目录

${project.build.directory} 构建目录，缺省为target

${project.build.outputDirectory} 构建过程输出目录，缺省为target/classes

${project.build.finalName} 产出物名称，缺省为${project.artifactId}-${project.version}

${project.packaging} 打包类型，缺省为jar

${project.xxx} 当前pom文件的任意节点的内容

六. 值得注意的问题

1. 继承父项目的方式有两种，分别是通过<parent>和在<denpendencyManagement>中使用<scope>为import，<type>为<pom>实现多继承。值得注意的是，前者继承而来的依赖的版本号可以通过在父项目中声明<properties>标签内进行修改和覆盖，而后者则不允许这么做。比如当前项目是A，打算导入pom.xml文件的依赖是B，B中包含了C(版本1.0)，而A中在<properties>标签内声明了C的版本号为2.0，且依赖了C(没有显示的写出版本号)，那么运行的结果是，A项目依赖的是1.0版本的C，<properties>不会起作用！原因在于maven在扫描A的<denpendencyManagement>时，C会直接因为B而被构建完成(版本1.0)，因为构建的顺序导致此时properties中的版本号声明不会起到任何作用。

想要覆盖import而来的版本号的问题有两个解决办法:1. 在<denpendencyManagement>中重新声明依赖C并写明版本号。2. 在启项目启动时使用-DXXX.version=XXXX来指定版本号

2 直接引用本地第三方jar包可以使用<systemPath>，但这样做不能将jar打包到最后的包中，因此还需要使用<includeSystemScope>true</includeSystemScope>

<plugins>
    <plugin>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-maven-plugin</artifactId>
        <configuration>
            <includeSystemScope>true</includeSystemScope>
        </configuration>
    </plugin>
</plugins>

爱喝咖啡的程序员

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
Maven知识点总结

一. 概念 Maven是一个用于项目构建和管理Jar包依赖的工具。二. Maven的优势 1. 项目构建。Maven整合了从清理、编译、测试到生成报告，再到打包和部署的全套自动化构建过程。 2. Jar管理。通过Maven的坐标系统，在仓库中能轻松的定位到任何一个java类库，我们可以借助它来有序的管理复杂的jar依赖。三....
复制链接

扫一扫