《Maven官方文档》-Maven依赖机制简介

最新推荐文章于 2021-12-23 17:08:16 发布
最新推荐文章于 2021-12-23 17:08:16 发布
阅读量133 收藏 1
点赞数
文章标签： java runtime python
原文链接：https://my.oschina.net/tantexian/blog/2988202
版权

2019独角兽企业重金招聘Python工程师标准>>> hot3.png

《Maven官方文档》-Maven依赖机制简介

原文地址 译者：Tyrian

依赖机制是Maven最为用户熟知的特性之一，同时也是Maven所擅长的领域之一。单个项目的依赖管理并不难，
但是当你面对包含数百个模块的多模块项目和应用时，Maven能帮你保证项目的高度控制力和稳定性。

大纲：

  •  传递性依赖
    • 排除、可选依赖
  • 依赖范围
  • 依赖管理
    • 导入依赖
  • 系统依赖

 

传递性依赖

传递性依赖是Maven2.0的新特性。假设你的项目依赖于一个库，而这个库又依赖于其他库。你不必自己去找出所有这些依赖，你只需要加上你直接依赖的库，Maven会隐式的把这些库间接依赖的库也加入到你的项目中。这个特性是靠解析从远程仓库中获取的依赖库的项目文件实现的。一般的，这些项目的所有依赖都会加入到项目中，或者从父项目继承，或者通过传递性依赖。
传递性依赖的嵌套深度没有任何限制，只是在出现循环依赖时会报错。
传递性依赖会导致包含库的依赖图增长的非常大。为了解决这个问题，Maven也提供了额外的机制，能让你指定哪些依赖会被包含：

  • 依赖调解 – 当项目中出现多个版本构件依赖的情形，依赖调解决定最终应该使用哪个版本。目前，Maven 2.0只支持“短路径优先”原则，意思是项目会选择依赖关系树中路径最短的版本作为依赖。当然，你也可以在项目POM文件中显式指定使用哪个版本。值得注意的是，在Maven2.0.8及之前的版本中，当两个版本的依赖路径长度一致时，哪个依赖会被使用是不确定的。不过从Maven 2.0.9开始，POM中依赖声明的顺序决定了哪个版本会被使用，也叫作”第一声明原则”。
    • “短路径优先”意味着项目依赖关系树中路径最短的版本会被使用。例如，假设A、B、C之间的依赖关系是A->B->C->D(2.0)和A->E->(D1.0)，那么D(1.0)会被使用，因为A通过E到D的路径更短。但如果你想要强制使用D(2.0)，那你也可以在A中显式声明对D(2.0)的依赖。
  • 依赖管理 – 在出现传递性依赖或者没有指定版本时，项目作者可以通过依赖管理直接指定模块版本。之前的章节说过，由于传递性依赖，尽管某个依赖没有被A直接指定，但也会被引入。相反的，A也可以将D加入<dependencyManagement>元素中，并在D可能被引用时决定D的版本号。
  • 依赖范围 – 你可以指定只在当前编译范围内包含合适的依赖。 下面会介绍更多相关的细节。
  • 排除依赖 – 如果项目X依赖于项目Y，项目Y又依赖项目Z，项目X的所有者可以使用”exclusion”元素来显式排除项目Z。
  • 可选依赖 – 如果项目Y依赖项目Z，项目Y的所有者可以使用”optional”元素来指定项目Z作为X的可选依赖。那么当项目X依赖项目Y时，X只依赖Y并不依赖Y的可选依赖Z。项目X的所有者也可以根据自己的意愿显式指定X对Z的依赖。（你可以把可选依赖理解为默认排除）。

 

依赖范围

依赖范围会影响传递性依赖，同时也会影响项目构建任务中使用的classpath。
Maven有以下6种依赖范围：

  • compile
    这是默认范围。如果没有指定，就会使用该依赖范围。编译依赖对项目所有的classpath都可用。此外，编译依赖会传递到依赖的项目。
  • provided
    和compile范围很类似，但provided范围表明你希望由JDK或者某个容器提供运行时依赖。例如，当使用Java EE构建一个web应用时，你会设置对Servlet API和相关的Java EE APIs的依赖范围为provided，因为web容器提供了运行时的依赖。provided依赖只对编译和测试classpath有效，并且不能传递。
  • runtime
    runtime范围表明编译时不需要依赖，而只在运行时依赖。此依赖范围对运行和测试classpath有效，对编译classpath无效。
  • test
    test范围表明使用此依赖范围的依赖，只在编译测试代码和运行测试的时候需要，应用的正常运行不需要此类依赖。
  • system
    系统范围与provided类似，不过你必须显式指定一个本地系统路径的JAR，此类依赖应该一直有效，Maven也不会去仓库中寻找它。
  • import（Maven2.0.9及以上）
    import范围只适用于pom文件中的<dependencyManagement>部分。表明指定的POM必须使用<dependencyManagement>部分的依赖。因为依赖已经被替换，所以使用import范围的依赖并不影响依赖传递。

每类依赖范围（除了import）通过不同方式影响传递性依赖，具体如下表所示。最左侧一列代表了直接依赖范围，最顶层一行代表了传递性依赖的范围，行与列的交叉单元格就表示最终的传递性依赖范围。表中的“-“表示该传递性依赖将会被忽略。

 compileprovidedruntimetest
compilecompile(*)–runtime–
providedprovided–provided–
runtimeruntime–runtime–
testtest–test–

(*)注意：这里本来应该是compile范围，那样的话compile范围都必须显式指定-然而，有这样一种情况，你依赖的、继承自其它库中的类的库必须在编译时可用。考虑到这个原因，即使在依赖性传递情况下，编译时依赖仍然是compile范围。

 

依赖管理

Maven提供了一个机制来集中管理依赖信息，叫做依赖管理元素”<dependencyManagement>”。假设你有许多项目继承自同一个公有的父项目，那可以把所有依赖信息放在一个公共的POM文件，并且在子POM中简单第引用该构件即可。通过一些例子可以更好的解释这个机制。下面是两个继承自同一个父项目的POM：

项目A

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

项目B

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

这两个POM都依赖于同一个模块，同时每个POM又各自依赖于一个无关的模块。父项目的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>
…
<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>
…
<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>

注意：在这两个POM文件的依赖中，我们必须指定<type/>元素。因为与依赖管理元素匹配的依赖引用最小信息集是{groupId, artifactId, type, classfier}。许多情况下，依赖指向的jar不需要指定classfier。因为默认type是jar，默认classfiler为空，所以我们可以把信息集设置为{groupId, artifactId}。

依赖管理元素第二个非常有用的功能是控制传递性依赖中构件的版本。例子如下
项目A：

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

项目B：

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

当在maven中有项目依赖B时，不管它们的pom文件中指定的版本是什么，构件a，b，c和d的版本都是1.0。

  • a和c都被声明为这个项目的依赖，根据依赖调解，a和c的版本都是1.0.同时a和c的依赖范围都被显式指定为runtime。
  • b定义在B的父项目的<dependencyManagement>元素中，因为在依赖性传递中<dependencyManagement>优先于依赖调解，所以b的版本是1.0，b是编译依赖范围。
  • 最后，d是定义在B的<dependencyManagement>元素中。

依赖管理的标签详细描述信息可以从这里获取项目描述符引用

导入依赖

这个章节描述的特性只在Maven2.0.9及之后的版本才有。这意味着更早版本的Maven不会解析包含import元素的pom文件。因此在使用该特性前，你必须慎重考虑。如果你打算使用这个特性，我们建议你使用enforcer插件来强制使用Maven2.0.9及以上版本。

前面的例子描述了怎么通过继承来指定管理的依赖。然而，这对于更大的项目通常会更复杂，因为一个项目只能继承自一个父项目。为了解决这个问题，项目可以导入其他项目的管理依赖，这可以通过声明依赖一个包含值为”import”的<scope>元素的构件来实现。

项目B：

<project>
<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>maven</groupId>
<artifactId>A</artifactId>
<version>1.0</version>
<type>pom</type>
<scope>import</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>1.0</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>test</groupId>
<artifactId>c</artifactId>
<scope>runtime</scope>
</dependency>
</dependencies>
</project>

假设A就是上一个例子中定义的POM，那么最终的结果也是一致的。除了在B中定义的d模块，所有A的管理依赖都会导入到B中。

项目X：

<project>
<modelVersion>4.0.0</modelVersion>
<groupId>maven</groupId>
<artifactId>X</artifactId>
<packaging>pom</packaging>
<name>X</name>
<version>1.0</version>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>test</groupId>
<artifactId>a</artifactId>
<version>1.1</version>
</dependency>
<dependency>
<groupId>test</groupId>
<artifactId>b</artifactId>
<version>1.0</version>
<scope>compile</scope>
</dependency>
</dependencies>
</dependencyManagement>
</project>

项目Y：

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

项目Z：

<project>
<modelVersion>4.0.0</modelVersion>
<groupId>maven</groupId>
<artifactId>Z</artifactId>
<packaging>pom</packaging>
<name>Z</name>
<version>1.0</version>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>maven</groupId>
<artifactId>X</artifactId>
<version>1.0</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>maven</groupId>
<artifactId>Y</artifactId>
<version>1.0</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
</project>

在上面的例子中，Z导入了X和Y的管理依赖。不过有个问题，X和Y都包含了依赖a。在这里，会使用1.1版本的a，因为X先被声明，并且a没有在Z的依赖管理中声明。

这个过程是递归进行的。假如X导入了另外的POM，Q，那么当解析Z的时候，所有Q的管理依赖看上去就都像在X中定义的一样。

当定义一个用于构建多项目的包含一些相关构件的依赖“库”时，导入依赖就十分有效。从“库”中引用一个或多个构件到项目中，是一种很常见的做法。然而，
保持项目中使用的依赖版本与库中发布的版本一致会有点麻烦。下面的模式描述了怎么生成一个供其它项目使用的“物料清单”（BOM）。

项目的根元素是BOM pom文件。它定义了库中创建的所有构件版本。其它要使用该库的项目必须将该pom导入到其pom文件中的<dependencyManagement>元素中。

<project xmlns=”http://maven.apache.org/POM/4.0.0″ 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”>
<modelVersion>4.0.0</modelVersion>
<groupId>com.test</groupId>
<artifactId>bom</artifactId>
<version>1.0.0</version>
<packaging>pom</packaging>
<properties>
<project1Version>1.0.0</project1Version>
<project2Version>1.0.0</project2Version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.test</groupId>
<artifactId>project1</artifactId>
<version>${project1Version}</version>
</dependency>
<dependency>
<groupId>com.test</groupId>
<artifactId>project2</artifactId>
<version>${project1Version}</version>
</dependency>
</dependencies>
</dependencyManagement>
<modules>
<module>parent</module>
</modules>
</project>

parent子项目将BOM pom作为它的父项目。这是一个简单的多项目pom。

<project xmlns=”http://maven.apache.org/POM/4.0.0″ 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”>
<modelVersion>4.0.0</modelVersion>
<groupId>com.test</groupId>
<artifactId>bom</artifactId>
<version>1.0.0</version>
<packaging>pom</packaging>
<properties>
<project1Version>1.0.0</project1Version>
<project2Version>1.0.0</project2Version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.test</groupId>
<artifactId>project1</artifactId>
<version>${project1Version}</version>
</dependency>
<dependency>
<groupId>com.test</groupId>
<artifactId>project2</artifactId>
<version>${project1Version}</version>
</dependency>
</dependencies>
</dependencyManagement>
<modules>
<module>parent</module>
</modules>
</project>

接下来是真正的pom文件。

<project xmlns=”http://maven.apache.org/POM/4.0.0″ 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”>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>com.test</groupId>
<version>1.0.0</version>
<artifactId>parent</artifactId>
</parent>
<groupId>com.test</groupId>
<artifactId>project1</artifactId>
<version>${project1Version}</version>
<packaging>jar</packaging>

<dependencies>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</dependency>
</dependencies>
</project>

<project xmlns=”http://maven.apache.org/POM/4.0.0″ 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”>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>com.test</groupId>
<version>1.0.0</version>
<artifactId>parent</artifactId>
</parent>
<groupId>com.test</groupId>
<artifactId>project2</artifactId>
<version>${project2Version}</version>
<packaging>jar</packaging>

<dependencies>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</dependency>
</dependencies>
</project>

下面的例子说明了怎么在项目中使用“库”，而不必指定依赖模块的版本。

<project xmlns=”http://maven.apache.org/POM/4.0.0″ 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”>
<modelVersion>4.0.0</modelVersion>
<groupId>com.test</groupId>
<artifactId>use</artifactId>
<version>1.0.0</version>
<packaging>jar</packaging>

<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.test</groupId>
<artifactId>bom</artifactId>
<version>1.0.0</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>com.test</groupId>
<artifactId>project1</artifactId>
</dependency>
<dependency>
<groupId>com.test</groupId>
<artifactId>project2</artifactId>
</dependency>
</dependencies>
</project>

最后，当创建引入依赖的项目时，需要注意以下几点：

  • 不要尝试引入在当前pom中定义的子模块pom。那会导致不能定位pom和编译失败。
  •  绝不要声明导入其他pom作为目标pom的父项目(或者祖父项目等)的pom文件。这会导致循环解析，并触发异常。
  •  当引用有传递性依赖的模块时，需要指定依赖模块的版本。不这样做，这些模块可能没有确定的版本，从而导致编译失败。（这在任何情况下都应该是一个最佳实践，因为它保证了模块版本的不变性）

系统依赖

系统范围的依赖应该是一直可用，并且Maven不会去仓库中查找。系统范围依赖通常是指JDK或者VM提供的依赖。所以，系统依赖适用于这种情况：以前可以单独获取，但现在是由JDK提供的依赖。典型的例子就是JDBC标准扩展或者Java认证和授权服务（JAAS）。一个简单的例子如下：

<project>
…
<dependencies>
<dependency>
<groupId>javax.sql</groupId>
<artifactId>jdbc-stdext</artifactId>
<version>2.0</version>
<scope>system</scope>
<systemPath>${java.home}/lib/rt.jar</systemPath>
</dependency>
</dependencies>
…
</project>

如果你的构件依赖于JDK的tools.jar，那么系统路径的值如下所示：

<project>
…
<dependencies>
<dependency>
<groupId>sun.jdk</groupId>
<artifactId>tools</artifactId>
<version>1.5.0</version>
<scope>system</scope>
<systemPath>${java.home}/../lib/tools.jar</systemPath>
</dependency>
</dependencies>
…
</project>

原创文章，转载请注明： 转载自并发编程网 – ifeve.com本文链接地址: 《Maven官方文档》-Maven依赖机制简介

cache-ads.png

Tyrian

Software Engineerat TP-LINK

Favorite添加本文到我的收藏

Related Posts:

  1. 《Maven官方文档》创建Archetype
  2. 《Maven官方文档》POM文件
  3. 《maven官方文档》5分钟开始Maven
  4. 《Maven官方指南》可选的依赖和依赖排除
  5. 《Maven官方文档》什么是原型(Archrtype)?
  6. spring boot集成mongodb最简单版
  7. Maven入门指南（二）
  8. Apache Storm 官方文档 —— 使用 Maven 构建 Storm 应用
  9. Spring Boot 集成 FreeMarker 详解案例
  10. Springboot 整合 Dubbo/ZooKeeper 详解 SOA 案例
  11. 《KAFKA官方文档》5.2 APIs
  12. Maven的Java插件开发指南
  13. Maven入门指南（一）
  14. Spring Boot 整合 Mybatis 实现 Druid 多数据源详解
  15. Spring Boot 整合 Redis 实现缓存操作

转载于:https://my.oschina.net/tantexian/blog/2988202

weixin_34414196
关注
maven传递依赖
while(True): print('adorable')
11-02 1056
python有pip, 我java有mvn。
apache-maven-3.9.6-bin
最新发布
01-07
Apache Maven 是一个强大的项目管理工具，广泛用于Java应用程序的构建、管理和依赖管理。Maven 3.9.6 是该工具的一个稳定版本，提供了一系列改进和优化，旨在提高开发效率和构建过程的可靠性。 Maven 使用一个约定...
《Maven官方文档》-Maven依赖机制简介（一）
weixin_34159110的博客
05-19 203
依赖机制是Maven最为用户熟知的特性之一，同时也是Maven所擅长的领域之一。单个项目的依赖管理并不难， 但是当你面对包含数百个模块的多模块项目和应用时，Maven能帮你保证项目的高度控制力和稳定性。 大纲： 传递性依赖 排除、可选依赖 依赖范围 依赖管理 导入依赖 系统依赖 传递性依赖 传递性依赖是Maven2.0的新特性。假设你的项目依...
Maven依赖机制理解
angou6476的博客
05-02 130
假设一个项目需要用到日志组件Log4j，那么有如下方式添加这个组件。 一、传统方式： 1、访问官网https://logging.apache.org/log4j/2.x/download.html，下载指定版本的jar包。 2、拷贝jar包到项目的lib目录，或者eclipse中指定依赖目录。 3、当有新版的Log4j更新，以上方式就要重新做一次。 那么问题来了，像Log4j...
[Maven实战]（9）传递性依赖
SmartSi
01-30 4782
了解Spring的朋友都知道，创建一个Spring Framework项目都需要依赖什么样的Jar包。如果不使用Maven，那么在项目中就需要手动下载相关的依赖。由于Spring Framework又会依赖与其他开源类库，因此实际中往往会下载Spring Framework的jar包，还的下载所有它依赖的其他jar包。这么做往往就引入了很多不必要的依赖。另一种做法是只下载Spring Framew
Maven的传递性依赖
C.
06-20 713
传递性依赖考虑一个基于Spring Framework的项目，如果不使用maven，那么在项目中就需要手动下载相关依赖。由于Spring Framework又会依赖于其他开源类库，因此实际中往往会下载一些很大的包，包含Spring Framework的jar包，以及所有依赖他的其他jar包，这样做往往会引入很多不必要的依赖包。或者还可能会造成很多错误信息，这是一个非常麻烦的事情。Maven的传递机制
apache-maven-3.9.0-bin.tar
03-13
Maven的插件系统也是其强大之处，通过安装额外的插件，可以支持更多的构建任务，如生成源码文档（javadoc）、执行单元测试（maven-surefire-plugin）、打包成不同格式（如JAR、WAR或EAR）等。 "linux版本maven"指的...
apache-maven-3.9.0-bin.tar.gz
02-09
Apache Maven 是一个强大的项目管理工具，广泛用于Java应用程序的构建、管理和依赖管理。Maven 使用一种标准的项目对象模型（Project Object Model，POM），通过POM文件来配置项目的构建过程，解决和管理项目的依赖...
apache-maven-3.9.5-bin windows 64bit x86下载
11-17
4、插件系统：Maven支持插件机制，你可以自定义插件来扩展Maven的功能。Maven自带了许多常用的插件，如编译、测试、打包插件等。 5、文档生成：Maven可以使用插件来生成项目的文档，如JavaDoc文档、站点文档等。 6...
apache-maven-3.8.4-bin.zip maven下载鬼慢
01-10
Maven还支持插件机制，允许扩展其功能，例如，你可以使用maven-javadoc-plugin生成API文档，maven-surefire-plugin执行单元测试，或者maven-site-plugin生成项目网站。在pom.xml中定义插件及其配置，即可实现这些...
maven 传递依赖
xiaomin1991222的专栏
03-28 226
依赖范围影响传递性依赖（左边第一行标示第一直接依赖范围，对上面第一行标示第二直接依赖范围，中间的交叉单元格标示传递性依赖范围）   compile test provided runtime compile compile --- --- runtime test test --- --- ...
maven的依赖传递性
enjoy.day
04-28 1022
maven的依赖传递性 当项目A依赖于B，而B又依赖于C的时候，自然的A会依赖于C，这样Maven在建立项目A的时候，会自动加载对C的依赖。 一、依赖传递对版本的选择 假设A依赖于B和C，然后B依赖于D，D又依赖于E1.0，C直接依赖于E2.0，那么这个时候A依赖的是E1.0还是E2.0，还是这两个都依赖呢？ 两个都依赖是肯定不行的，因为它们可能会有冲突的地方。这个时候就涉及到Maven中依赖传递对版本的选择问题。 依赖传递在选择版本的时候首先是根据深度选择的。当一个项目同时经过不同的路径依赖于同一个组件时
Maven 依赖机制
weixin_44684812的博客
10-28 320
Maven 依赖机制（三） 在 Maven 依赖机制的帮助下自动下载所有必需的依赖库，并保持版本升级。 Log4j 作为项目的日志,作为例子。 传统方式 访问 http://logging.apache.org/log4j/ 下载 Log4j 的 jar 库 复制 jar 到项目类路径 手动将其包含到项目的依赖 所有的管理需要一切由自己做 如果有 Log4j 版本升级，则需要重复上述步骤一次...
Maven的依赖机制
蚂蚁小帅哥的专栏
09-19 360
在Maven依赖机制的帮助下自动下载所有必要的依赖库，并保持升级。 案例分析：比如项目需要使用Log4j作为项目的日志 传统方式： 访问 http://logging.apache.org/log4j/ 下载 Log4 j的 jar 库 复制 jar 到项目类路径 手动将其包含到项目的依赖 所有的管理需要一切由自己做 如果有 Log4j 版本升级，则需要重复上述步骤一次。
maven3实战之坐标和依赖(依赖调解)
fhd001的专栏
06-19 134
maven3实战之坐标和依赖(依赖调解) ----------- maven引入的传递性依赖机制，一方面大大简化和方便了依赖声明，另一方面，大部分情况下我们只需要关心项目的直接依赖是什么，而不用考虑这些直接依赖会引入什么传递性依赖。但有时候，当传递性依赖造成问题的时候，我们就需要清楚地知道该传递性依赖是从哪条依赖路径引入的。   例如，项目A有这样的依赖关系 ： A--&gt;B--...
Maven依赖机制-参考官方文档
weixin_39400721的博客
08-11 371
Maven 依赖机制 一来管理是 Maven 的核心功能。Maven 在定义，创建和维护具有明确定义的类路径和库版本的可复制构建方面大有帮助。 传递依赖关系 Maven 通过自动包含传递性依赖关系，避免了发现和指定你自己的依赖关系所需库的需要（官方文档里的说法）。 也就是说，Maven会根据你引入 pom 的依赖来自动管理各依赖之间的关系，而它们有可能是继承自父项目或者它本身。因此可能会有多个不同版本的同一依赖，然而只有在发生循环依赖的时候才会产生问题。 Maven 自身包含一些功能来限制引入哪些依赖项：
3. maven依赖传递
lucyLee的博客
03-21 3092
依赖范围 上一篇博客提到，在pom文件中引用其他依赖时，可以指定依赖的范围 例如，test范围支队测试代码有效，对编译或运行主代码无效 这里maven在编译、运行和测试时，会使用三套不同的classpath：编译classpath、运行classpath、测试classpath。 依赖范围，就是用来控制引入的依赖与这三种classpath之间的关系 。 maven的中依赖范围： compile： 编译依赖范围，若不明确指定scope，默认使用该值。compile范围的依赖，对编译classpath、
maven依赖机制简介
weixin_38038479的博客
12-23 549
maven依赖机制官方文档 文章目录1，依赖性调解2，依赖关系管理3，依赖范围4，排除依赖项5，可选依赖项 可传递的依赖，maven 会自动包含那些你直接依赖的库所需要的依赖库，前提是那些被简介依赖的库是可传递的； 基于这个特性，需要有以下这些规定：（解决版本冲突） 1，依赖性调解 决定了当遇到多个版本作为依赖项时，哪个版本作为依赖项。默认的是 "最接近定义"； a->b->c->d1 a->e->d2 d2离a 比 d1离 a 近，则 d2被作为依赖版本 a->b-&
【Maven】传递性依赖
飞翔的肥仔
09-09 539
假设A依赖于B和C，然后B依赖于D，D又依赖于E1.0，C直接依赖于E2.0，那么这个时候A依赖的是E1.0还是E2.0，还是这两个都依赖呢？两个都依赖是肯定不行的，因为它们可能会有冲突的地方。这个时候就涉及到Maven中依赖传递对版本的选择问题。依赖传递在选择版本的时候首先是根据深度选择的。     当一个项目同时经过不同的路径依赖于同一个组件时，会选择其深度最短的对应组件进行依赖。举例来说，
《Maven实战》- Maven技术专家许晓斌解读
《Maven实战》一书由许晓斌，一位资深的Maven专家所著，旨在解决Maven在早期推广中遇到的学习难度和文档不足的问题。书中的内容反映了作者从个人研究到团队推广，再到在Sonatype公司参与Nexus开发与维护Maven中央...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值