Maven-依赖管理机制

已于 2023-11-24 18:33:50 修改
阅读量625 收藏
点赞数 1
分类专栏： 开发工具 文章标签： maven java
于 2023-11-10 18:17:34 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/wlphlj/article/details/134312702
版权

前言

一、背景和起源

依赖管理是Maven的一个核心功能。管理单模块项目的依赖相对比较容易，管理多模块项目依赖或者有几百个模块项目的依赖就是一个巨大的挑战。
如果手动构建项目，那么就先需要梳理各个模块pom中定义的依赖，然后将依赖下载到本地，并且还需要将依赖中pom定义的依赖下载，如此反复。这中间需要解决相同依赖版本不同、依赖排除等情况。

二、依赖配置

项目对外部库的依赖，可以配置在pom文件的dependency节点，需要提供依赖的groupId，artifactId，version。例如：

<dependency>
    <groupId>org.apache.hadoop</groupId>
    <artifactId>hadoop-mapreduce-client-core</artifactId>
    <version>3.2.2</version>
    <scope>provided</scope>
    <exclusions>
       <exclusion>
          <groupId>com.google.guava</groupId>
          <artifactId>guava</artifactId>
       </exclusion>
    </exclusions>
</dependency>

三、传递依赖

传递依赖机制是指项目只需要在POM中定义直接依赖、不需要定义任何间接依赖。Maven会读取各直接依赖的POM，将必要的间接依赖引入到当前项目。传递依赖机制简化了POM的配置，也将开发者从依赖的复杂传递关系中解脱出来。

1.依赖仲裁机制

当项目出现多版本依赖时，maven就需要通过依赖仲裁机制决定选择哪个版本依赖。

  • 路径优先：依赖层级越浅优先越高，层级越深优先级越低
  • 声明优先：当依赖所在层级相同，声明靠前的依赖优先级高于声明靠后的优先级

2.依赖范围

依赖范围会限制一些依赖在传递依赖机制中的传递，也就是一些间接依赖可能不会引入到当前项目中。传递范围Scope主要分为六种：

  • compile： 编译期，scope默认范围。也就是从编译期直到运行期都需要此依赖。
  • provided： 表示运行容器或者jdk提供的依赖，只需要在编译期引入此依赖，打包成运行程序时不需要包含此依赖。
  • runtime： 表示测试和运行期需要引入此依赖，编译期不需要此依赖，但打包时需要包含此依赖。
  • test： 测试期需要引入此依赖，编译期和打包时都不需要包含此依赖
  • system： 与provided类似，运行期间由用户指定的系统路径提供依赖
  • import：用于引入外部定义的依赖版本管理文件，相当于将依赖版本声明在pom的dependencyManagement节点。

以上依赖范围的依赖在整个构建和运行期间起作用范围如下：
在这里插入图片描述

3.依赖范围对传递的限制

项目A的pom中定义依赖项目B并且Scope为X，项目B中pom中定义依赖项目C并且Scope为Y。根据Maven传递依赖的机制，项目A不仅会加载直接依赖B还会加载间接依赖C，但是以上Scope X和Y会对是否加载依赖C以及依赖C的作用范围产生影响。

传递性依赖范围影响受到Scope X和Scop Y的影响如下：
在这里插入图片描述
注意：列为Scope X，行为Scope Y，交叉部分为项目A中针对依赖C的作用范围，当表格中为‘-’时，表示项目A不会引入依赖C。

4.排除依赖

如果当前项目只想引入直接依赖和部份间接依赖，这样需要将某个间接依赖排除掉，这样可以通过设置exclusions来实现。

比如以下例子就是排除间接依赖guava包。

<dependency>
    <groupId>org.apache.hadoop</groupId>
    <artifactId>hadoop-mapreduce-client-core</artifactId>
    <version>3.2.2</version>
    <scope>provided</scope>
    <exclusions>
       <exclusion>
          <groupId>junit</groupId>
          <artifactId>junit</artifactId>
       </exclusion>
    </exclusions>
</dependency>

5.可选依赖

如果当前项目在被依赖时，默认情况下想将当前项目的直接依赖不被加载可以用可选依赖。功能相当于当前项目被引用时配置了exclusions节点。

比如以下例子就是排除间接依赖guava包。

<dependency>
	<groupId>junit</groupId>
	<artifactId>junit</artifactId>
	<version>4.12</version>
	<!-- 配置不透明 -->
	<optional>true</optional>
</dependency>

四、依赖集中管理

pom中dependencies节点可以定义项目需要引用的依赖，如果是一个多module项目，那么每个module中pom定义的依赖可能出现版本不一致，可能会出现版本冲突并且在升级版本时也不方便集中管理。所以可以在pom中的dependencyManagement节点对依赖的版本、范围、排除项等进行集中管理，这样整个项目中的版本可以保持一致并且方便进行版本管控。

1.父pom集中管理

当项目中有多个module时，可以在项目pom的dependencyManagement节点对依赖进行集中管理，来决定引入依赖的版本、排除间接依赖、依赖范围等。module中的pom将项目pom作为父pom，module中的pom只定义dependencies节点来决定引入哪些依赖。

1.1 不使用dependencyManagement对依赖进行管理

如果项目不是用dependencyManagement管理，则两个项目的pom可以如下进行配置，其中依赖必须包含{groupId, artifactId, type}。
Project A POM：

<project>
  ...
  <dependencies>
    <dependency>
      <groupId>group-a</groupId>
      <artifactId>artifact-a</artifactId>
      <version>1.0</version>
      <exclusions>
        <exclusion>
          <groupId>group-c</groupId>
          <artifactId>excluded-artifact</artifactId>
        </exclusion>
      </exclusions>
    </dependency>
    <dependency>
      <groupId>group-a</groupId>
      <artifactId>artifact-b</artifactId>
      <version>1.0</version>
      <type>bar</type>
      <scope>runtime</scope>
    </dependency>
  </dependencies>
</project>

Project B POM：

<project>
  ...
  <dependencies>
    <dependency>
      <groupId>group-c</groupId>
      <artifactId>artifact-b</artifactId>
      <version>1.0</version>
      <type>war</type>
      <scope>runtime</scope>
    </dependency>
    <dependency>
      <groupId>group-a</groupId>
      <artifactId>artifact-b</artifactId>
      <version>1.0</version>
      <type>bar</type>
      <scope>runtime</scope>
    </dependency>
  </dependencies>
</project>

1.2 使用dependencyManagement对依赖进行管理

为了简化和统一管理，可以将以上两个项目所有的依赖版本管理统一放到父pom中，这样两个项目中依赖定义可以只定义 {groupId, artifactId}。
Parent Project POM：

<project>
  ...
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>group-a</groupId>
        <artifactId>artifact-a</artifactId>
        <version>1.0</version>
        <exclusions>
          <exclusion>
            <groupId>group-c</groupId>
            <artifactId>excluded-artifact</artifactId>
          </exclusion>
        </exclusions>
      </dependency>
 
      <dependency>
        <groupId>group-c</groupId>
        <artifactId>artifact-b</artifactId>
        <version>1.0</version>
        <type>war</type>
        <scope>runtime</scope>
      </dependency>
 
      <dependency>
        <groupId>group-a</groupId>
        <artifactId>artifact-b</artifactId>
        <version>1.0</version>
        <type>bar</type>
        <scope>runtime</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>
</project>

两个项目中的pom配置可以简化为：
Project A POM：

<project>
  ...
  <dependencies>
    <dependency>
      <groupId>group-a</groupId>
      <artifactId>artifact-a</artifactId>
    </dependency>
 
    <dependency>
      <groupId>group-a</groupId>
      <artifactId>artifact-b</artifactId>
      <!-- This is not a jar dependency, so we must specify type. -->
      <type>bar</type>
    </dependency>
  </dependencies>
</project>

Project B POM：

<project>
  ...
  <dependencies>
    <dependency>
      <groupId>group-c</groupId>
      <artifactId>artifact-b</artifactId>
      <!-- This is not a jar dependency, so we must specify type. -->
      <type>war</type>
    </dependency>
 
    <dependency>
      <groupId>group-a</groupId>
      <artifactId>artifact-b</artifactId>
      <!-- This is not a jar dependency, so we must specify type. -->
      <type>bar</type>
    </dependency>
  </dependencies>
</project>

2.当前pom和父pom一起集中管理

依赖集中管理也支持传递依赖，也就是集中管理当pom和父pom都配置了，这两个都会对依赖起到管理作用。
例如Project B继承了Project A，并且两个都定义了依赖管理。
Project A POM：

<project>
 <modelVersion>4.0.0</modelVersion>
 <groupId>maven</groupId>
 <artifactId>A</artifactId>
 <packaging>pom</packaging>
 <name>A</name>
 <version>1.0</version>
 <dependencyManagement>
   <dependencies>
     <dependency>
       <groupId>test</groupId>
       <artifactId>a</artifactId>
       <version>1.2</version>
     </dependency>
     <dependency>
       <groupId>test</groupId>
       <artifactId>b</artifactId>
       <version>1.0</version>
       <scope>compile</scope>
     </dependency>
     <dependency>
       <groupId>test</groupId>
       <artifactId>c</artifactId>
       <version>1.0</version>
       <scope>compile</scope>
     </dependency>
     <dependency>
       <groupId>test</groupId>
       <artifactId>d</artifactId>
       <version>1.2</version>
     </dependency>
   </dependencies>
 </dependencyManagement>
</project>

Project B POM：

<project>
  <parent>
    <artifactId>A</artifactId>
    <groupId>maven</groupId>
    <version>1.0</version>
  </parent>
  <modelVersion>4.0.0</modelVersion>
  <groupId>maven</groupId>
  <artifactId>B</artifactId>
  <packaging>pom</packaging>
  <name>B</name>
  <version>1.0</version>
 
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>test</groupId>
        <artifactId>d</artifactId>
        <version>1.0</version>
      </dependency>
    </dependencies>
  </dependencyManagement>
 
  <dependencies>
    <dependency>
      <groupId>test</groupId>
      <artifactId>a</artifactId>
      <version>1.0</version>
      <scope>runtime</scope>
    </dependency>
    <dependency>
      <groupId>test</groupId>
      <artifactId>c</artifactId>
      <scope>runtime</scope>
    </dependency>
  </dependencies>
</project>

当构建项目B时，依赖a、依赖b、依赖c 都是版本1.0被使用。

  • 依赖a：由于在项目B中直接定义了版本号和scope，所以最终是加载的依赖a版本号为1.0、scope为runtime。
  • 依赖c：由于在项目B中只定义了scope，所以版本号需要由dependencyManagement节点决定，所以最终是加载的依赖c版本号为1.0、scope为runtime。
  • 依赖b：如果依赖b被依赖a或者依赖c间接引用，那么依赖b的版本由父pom中dependencyManagement节点决定，所以最终是加载的依赖b版本号为1.0、scope为compile。
  • 依赖d：因为项目B和父pom都在dependencyManagement节点定义了依赖d，所以管理节点是项目B中为准。

3.引入外部集中管理

如果项目module过多，没办法继承同一个父pom。这样可以通过引入一个外部的pom，这个pom只有dependencyManagement节点。

五、依赖版本确定流程

依赖版本的查找与依赖传递的解决机制都是基于项目Pom，也就是当项目有多个module时，是会按照每个module的pom为基本单位进行依赖的查找和传递。
例如：有父项目ProjectA，下边有子项目ProjectB和ProjectC。子项目ProjectC依赖ProjectB。

Project A POM：

<project>
 <modelVersion>4.0.0</modelVersion>
 <groupId>maven</groupId>
 <artifactId>A</artifactId>
 <packaging>pom</packaging>
 <name>A</name>
 <version>1.0</version>
 <dependencyManagement>
   <dependencies>
     <dependency>
       <groupId>test</groupId>
       <artifactId>a</artifactId>
       <version>1.2</version>
     </dependency>
     <dependency>
       <groupId>test</groupId>
       <artifactId>b</artifactId>
       <version>1.0</version>
       <scope>compile</scope>
     </dependency>
     <dependency>
       <groupId>test</groupId>
       <artifactId>c</artifactId>
       <version>1.0</version>
       <scope>compile</scope>
     </dependency>
     <dependency>
       <groupId>test</groupId>
       <artifactId>d</artifactId>
       <version>1.2</version>
     </dependency>
   </dependencies>
 </dependencyManagement>
</project>

Project B POM：

<project>
  <parent>
    <artifactId>A</artifactId>
    <groupId>maven</groupId>
    <version>1.0</version>
  </parent>
  <modelVersion>4.0.0</modelVersion>
  <groupId>maven</groupId>
  <artifactId>B</artifactId>
  <packaging>pom</packaging>
  <name>B</name>
  <version>1.0</version>
 
  <dependencyManagement>
    <dependencies>
      <dependency>
      <groupId>test</groupId>
      <artifactId>a</artifactId>
      <version>2.4</version>
      <scope>runtime</scope>
    </dependency>
     <dependency>
      <groupId>test</groupId>
      <artifactId>a</artifactId>
      <version>2.5</version>
      <scope>compile</scope>
    </dependency>
    <dependency>
       <groupId>test</groupId>
       <artifactId>c</artifactId>
       <version>2.1</version>
       <scope>compile</scope>
     </dependency>
      <dependency>
        <groupId>test</groupId>
        <artifactId>d</artifactId>
        <version>1.0</version>
      </dependency>
    </dependencies>
  </dependencyManagement>
 
  <dependencies>
    <dependency>
      <groupId>test</groupId>
      <artifactId>a</artifactId>
      <version>3.6</version>
      <scope>runtime</scope>
    </dependency>
     <dependency>
      <groupId>test</groupId>
      <artifactId>a</artifactId>
      <version>3.7</version>
      <scope>runtime</scope>
    </dependency>
    <dependency>
      <groupId>test</groupId>
      <artifactId>c</artifactId>
      <scope>runtime</scope>
    </dependency>
  </dependencies>
</project>

Project C POM：

<project>
  <parent>
    <artifactId>A</artifactId>
    <groupId>maven</groupId>
    <version>1.0</version>
  </parent>
  <modelVersion>4.0.0</modelVersion>
  <groupId>maven</groupId>
  <artifactId>B</artifactId>
  <packaging>pom</packaging>
  <name>B</name>
  <version>1.0</version>
 
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>test</groupId>
        <artifactId>d</artifactId>
        <version>1.0</version>
      </dependency>
      <dependency>
        <groupId>test</groupId>
        <artifactId>a</artifactId>
        <version>2.3</version>
      <scope>runtime</scope>
    </dependency>
    </dependencies>
  </dependencyManagement>
 
  <dependencies>
    <dependency>
      <groupId>test</groupId>
      <artifactId>a</artifactId>
      <version>3.0</version>
      <scope>runtime</scope>
    </dependency>
    <dependency>
      <groupId>test</groupId>
      <artifactId>c</artifactId>
      <scope>runtime</scope>
    </dependency>
  </dependencies>
</project>

1.配置优先级

1.1 不同节点优先级

同一个Pom中dependencies优先级高于dependencyManagement。比如在Project C中dependencies中定义了依赖a的版本和scope，所以会忽略dependencyManagement中依赖a的版本和scope。依赖a会采用版本3.0。

1.2 不同pom中dependencyManagement优先级

父子Pom中子Pom中dependencyManagement优先级高于父Pom中的dependencyManagement。比如在Project B中dependencies中没有定义了依赖c的版本，并且dependencyManagement定义了依赖c版本为2.1, 所以会忽略ProjectA中dependencyManagement中依赖c的版本和scope。

1.3 重复定义优先级

dependency在同一个dependencies或dependencyManagement中，如果出现相同{groupId,artifactId}，则后出现的会覆盖先出现。
比如在Project B中dependencies和dependencyManagement中重复定义了依赖a，所以在各自节点中，起作用的都是后定义的版本。按照目前Pom，依赖a会是3.7，如果删除dependencies对依赖a的定义，则依赖a会采用版本2.5。

2.版本确定流程

2.1 对Pom的dependencies中定义的{groupId,artifactId}组合顺序遍历，如果有相同组合以后定义的信息为主。
2.2 针对以上去重后每个租户，如果version和exclusions都明确定义了，则确定了此依赖。
2.3 如果version和exclusions有一个没有定义，如果本Pom中dependencyManagement中定义了此依赖信息，则进行加载此依赖。
2.4 如果本Pom中dependencyManagement中没有定义了此依赖，则去父Pom的dependencyManagement中查找此依赖定义，如果没有会一直查找到默认Pom文件对应节点
2.5 将依赖的Pom的dependencies按照 2.1进行处理后，还需要去掉exclusions的租户后跳转到2.2。
2.6 如果加载完成所有依赖，出现了相同{groupId,artifactId}，则需要根据仲裁机制的路径优先和声明优先进行选择。
在这里插入图片描述

3.版本冲突

maven有完善的版本管理和冲突解决机制，但是为什么实际工程中还会出现依赖多版本和冲突问题。主要是因为maven的冲突仲裁机制是以Pom为单位进行的，如果一个项目有很大module，而对依赖版没有进行统一管理，就会出现相同的依赖在不同module的版本不一致问题。
例如上边的例子依赖a在Project B中引入的是2.5版本，在Project C中引入的是3.0版本。所以针对整个项目在运行过程中可能会优先加载2.5版本，这就导致Project C中调用依赖3.0版本a的一些方法缺失或者实现有差异，导致功能异常。

3.1 版本统一管理

将所有版本管理统一到父Pom的dependencyManagement中，子项目中不要配置dependencyManagement。

3.2 排除依赖

可以在子项目定义依赖时通过exclusions将一些间接依赖排除掉，解决版本冲突。

总结

主要是对maven依赖传递机制的介绍、依赖管理的的配置、依赖版本和范围确定机制、依赖冲突解决等。

参考

1.maven文档-依赖机制

临江蓑笠翁
关注
  • 1
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
六、依赖管理
一个孤独漫步者的遐想的博客
06-23 167
六、依赖管理基本概念直接依赖和间接依赖依赖的范围依赖的传递性依赖的原则依赖的排除统一管理目标 基本概念 当 A jar 包需要用到 B jar 包中的类时，我们就说 A 对 B 有依赖。例如：commons-fileupload-1.3.jar 依赖于 commons-io-2.0.1.jar 通过第二个 Maven 工程我们已经看到，当前工程会到本地仓库中根据坐标查找它所依赖的 jar 包。配置的基本形式是使用 dependency 标签指定目标 jar 包的坐标。例如： <dependencies
apache-maven-3.6.1 安装包
02-11
3. **依赖管理**：Maven通过读取POM中的依赖配置，自动下载并管理项目的依赖库，避免了版本冲突和手动管理库的问题。它遵循“最接近优先”原则，如果多个依赖有相同jar，会选择离当前项目最近的依赖版本。 4. **...
持续集成之“依赖管理”
cpongo5
05-15 130
在前文《分支策略(续)》中，我们讨论了多组件应用程序的持续集成策略，即：为相对独立的组件创建自己专属的代码库，然后通过现代持续集成工具进行组件间的持续集成。Joe的团队在首次发布之后，开始使用这种方式。然而，没有多久，他们就遇到了一个问题：一次提交构建所花费的时间太长。\一天，Joe就早早地来到了办公室。因为他前一天下班前，他开发的用户故事还有一小点就完事儿了。他想利用早上这点儿时间把它搞完，交给...
Maven Dependency Mechanism - 依赖管理机制
JackyCheng2007
02-25 187
[b]Dependency Mechanism[/b] Java项目开发中肯定需要大量的jar文件，也就是说你要依赖很多已经开发好的jar包。尤其是你要依赖很多开源的东东。有没有感到很迷糊，经常不知道要用到哪些，干脆全部拿来。多么希望用多少来多少，还不用我自己指定。再加上版本的问题，头大。maven号称有奇招。我们来看看maven的依赖管理机制吧。 [code="java"] ...
依赖管理
代码人生的专栏
10-25 141
完成不同需求的Spring应用构建，Spring Boot提供了多种不同的依赖管理模板，每种模板均为一系列已完成的依赖的管理。例如如需要构建web项目，我们只需添加spring-boot-starter-web的依赖即可，它会将你所需的其他依赖导入到你的工程中。官方称之为“物料清单”（Bills of Materials），也因此在使用时我们需要构建工具的支持，如Maven或者Gradle等。 Spring Boot提供了多种不同的Starters来满足我们对不同“物料清单的需求”，这些Starters均为
maven资源 apache-maven-3.3.9-bin.zip
03-07
Apache Maven 是一个强大的Java项目管理和综合工具，它简化了构建过程，通过标准化构建生命周期和依赖管理，使得开发者能够更高效地构建、测试和部署Java应用程序。Maven 3.3.9是Maven的一个稳定版本，它包含了多个...
Maven仓库apache-maven-3.2.5
06-30
总结来说，Apache Maven 3.2.5是一个强大而灵活的Java项目管理工具，它通过统一的构建生命周期、依赖管理和仓库机制，简化了项目的构建和维护工作。这个版本在性能和稳定性上做了优化，为开发者提供了更高效、更友好...
apache-maven-3.8.1-bin.zip
05-22
3. **依赖管理**： - Maven通过读取POM.xml中的依赖信息，自动下载并管理项目所需的库文件，避免了手动管理jar文件的繁琐工作。 4. **构建生命周期**： - Maven具有清晰的构建生命周期，包括`clean`（清理）、`...
maven-archetype-quickstart-1.1.jar包下载
06-21
Maven是Java开发中的一款强大的构建工具，它简化了项目的构建、依赖管理和生命周期过程。`maven-archetype-quickstart-1.1.jar` 是一个Maven的快速启动 archetype 包，专门用于帮助开发者快速创建一个新的Maven项目...
Maven 依赖管理机制
qq_42692592的博客
02-24 168
目录传递依赖依赖调解依赖管理依赖作用域 传递依赖 传递依赖没有级别限制, 只有出现循环依赖问题 依赖调解 依赖调解决定当出现多个不同版本的依赖时使用哪个版本.但是你也可以在你的项目显式指定依赖的版本. 当出现多个不同版本的依赖时,依赖调解使用就近原则来选择依赖的版本,即根据依赖传递的深度来判断,传递深度越低的优先. 如果出现多个相同深度的传递依赖时,先定义的优先. A ├── B │ └── C │ └── D 2.0 └── E └── D 1.0 项目A中D
依赖管理：dependencyManagement
m0_51963973的博客
04-13 916
当项目工程比较大，存在多个模块时，会在父模块中使用dependencyManagement组件，所有的子项目只需要在父pom 的 “公共依赖声明池” 中挑选自己想要的依赖，而不用关心版本。这样即不会继承到不需要的依赖，又统一了依赖的版本。如果某个子项目不想使用公共的版本号，只需要在 dependency 中加上版本号，子项目就会使用自定义的版本号，不会继承父类版本号。如果想统一调整所有子项目某个依赖的版本，只需要在父pom 里更新。不需要修改任何一个子项目。
【Maven】——依赖管理
漫漫长途，终有回转；余味苦涩，终有回甘
03-03 320
一般在Maven项目中会引用很多依赖jar包，本文主要讲解Maven中关于依赖的内容。如有理解偏颇之处，欢迎各位大神指正。 依赖范围 compile：编译依赖范围。如果没有指定，默认会使用该依赖范围。使用此依赖范围，在编译，测试，运行时候都有效，都会使用该依赖 test：测试依赖范围。只在测试有效，在编译主代码或运行项目的时候无法使用此类依赖，典型Junit，它...
maven详解--依赖管理
EQwer123的博客
03-30 314
**maven详解--依赖管理** 什么是依赖管理? maven提供了一套依赖管理机制，通过在pom.xml定义坐标，通过坐标从互联网的中央仓库下载依赖的构件（jar包），规范去管理依赖所有构件。 仓库管理? maven的依赖管理依赖于仓库，仓库中存储了jar包（所有项目可能使用的依赖的构件） 本地仓库： 工程所依赖的jar包先从本地仓库找。 本地仓库在和工程同一个电脑，本地仓库的默认地址/用户/.m2/respsitory 中央仓库： 是maven默认的一个远程仓库,...
依赖管理工具
07-14 307
第三方
Maven依赖管理
HGW的博客
03-30 1635
maven中依赖的范围、依赖的传递、依赖的排除、继承、聚合、属性、版本管理、资源配置、多环境开发配置等
【maven】--依赖管理
lyn
12-10 1153
其中一个Maven的核心特征是依赖管理。管理依赖关系变得困难的任务一旦我们处理多个模块项目（包含数百个模块/子项目）。Maven提供了一个高程度的控制来管理这样的场景。 传递依赖发现 这是很通常情况下，当一个库说甲就依赖于其他库说乙的情况下，另一个项目Ç想用A，则该项目需要使用库中B. Maven通过读取依赖项目文件（pom.xml中），找出它们的依赖等。 我们只需要在每个项目中POM定义
依赖管理——依赖配置、依赖传递、依赖传递的冲突问题、可选依赖、排除依赖、依赖的范围（详细）
weixin_51351637的博客
04-03 1187
一、依赖配置 依赖指当前项目运行所需的jar，一个项目可以设置多个依赖。 格式：<dependencies>标签中，可以添加多个依赖 （配置完成之后，记得刷新一下，就不用像以前那样copyjar包了） <!-- 设置工程的所有依赖--> <dependencies> <!-- 具体的依赖--> <dependency> <!-- 依赖所属群组id --> <groupId>jun.
apache-maven-3.6.3-bin.zip
最新发布
07-31
apache-maven-3.6.3-bin.zip 是 Apache Maven 的一个压缩文件。Apache Maven 是一个用于构建和管理Java项目的工具。它提供了一个高度可配置的、基于项目对象模型（Project Object Model，POM）的构建系统。Maven 使用 XML 格式的 POM 文件来描述项目的结构、依赖关系和构建过程。 apache-maven-3.6.3-bin.zip 是 Maven 的一个二进制压缩文件，包含了 Apache Maven 3.6.3 版本的所有二进制文件和可执行文件。当你下载和解压缩这个文件时，你将获得 Maven 运行所需的所有必要文件和目录结构。 通过使用 apache-maven-3.6.3-bin.zip，你可以轻松地设置 Maven 环境，并且可以在命令行或集成开发环境（IDE）中使用 Maven。你可以使用 Maven 命令进行模块化构建、依赖管理、测试执行、打包、发布和部署等操作。同时，Maven 还提供了丰富的生命周期和插件机制，方便你扩展和定制构建过程。 总而言之，apache-maven-3.6.3-bin.zip 是 Apache Maven 3.6.3 版本的二进制压缩文件，通过安装和配置这个文件，你可以使用 Maven 来构建和管理你的 Java 项目。它为开发者提供了一种简单、高效和标准化的方式来处理项目的构建和依赖管理。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值