Maven使用exclusions排除依赖-笔记

1. 标签功能介绍

在 Maven 的依赖管理中， 标签用于排除某个依赖的传递性依赖（transitive dependencies）。当引入一个依赖时，Maven 会自动引入其依赖的库（即传递依赖），但有时这些依赖可能与项目中的其他依赖冲突、版本不一致，或者不需要它们。此时，可以通过  明确排除这些不需要的依赖，从而优化依赖树或解决版本冲突问题。

功能介绍

1. 作用对象
    仅作用于当前依赖的直接依赖，即该依赖声明中明确列出的依赖项。它不会影响其他依赖路径引入的相同依赖。例如，pomA依赖B和C，其中B和C都依赖commons-logging，pomA在引入B时使用排除了对commons-logging的依赖，而因C引入的 commons-logging依然会被保留。

2. 排除方式
   通过指定要排除的依赖的 groupId 和 artifactId，Maven 会从当前依赖的依赖树中移除匹配的依赖项。版本号不需要指定，因为排除操作不依赖版本。

3. 典型使用场景

   • 解决版本冲突：当多个依赖引入了同一库的不同版本时，排除其中一个版本。
   • 减少冗余依赖：移除不必要的传递依赖以简化构建。
   • 避免依赖冲突：例如，排除旧的日志框架（如 commons-logging）以适配新日志实现（如 SLF4J）。

2. 使用示例

2.1 避免依赖冲突

在 Maven 项目中，当需要从旧的日志框架（如 commons-logging）迁移到新日志实现（如 SLF4J）时，可能会遇到依赖冲突的问题。某些第三方库可能仍然依赖 commons-logging，而项目希望统一使用 SLF4J 作为日志门面。此时可以通过  标签排除这些库中引入的 commons-logging，从而避免日志框架冲突。

示例场景：假设你的项目中引入了 org.apache.httpcomponents:httpclient，它默认依赖 commons-logging：

    org.apache.httpcomponents
    httpclient
    4.5.13

而你的项目希望统一使用 SLF4J 作为日志门面，并通过 logback 作为底层实现。此时，commons-logging 会与 SLF4J 的绑定逻辑冲突，可能导致以下问题：

• 运行时抛出 NoClassDefFoundError（例如找不到 org.apache.commons.logging.Log）。
• 日志输出混乱，或无法正确绑定到 logback。

---

解决方案：使用  排除 commons-logging。在 httpclient 的依赖中，通过  显式排除 commons-logging，并添加 SLF4J 和 logback 的依赖：

    
    
        org.apache.httpcomponents
        httpclient
        4.5.13
        
            
                commons-logging
                commons-logging
            
        
    

    
    
        org.slf4j
        slf4j-api
        1.7.36
    

    
    
        ch.qos.logback
        logback-classic
        1.2.11
    

作用说明

1. 排除 commons-logging

   • httpclient 依赖的 commons-logging 被移除，避免与 SLF4J 的绑定逻辑冲突。
   • 项目中所有日志调用将统一通过 SLF4J 的 API（如 org.slf4j.Logger）进行。

2. 添加 SLF4J 和 logback

   • 显式声明 SLF4J 的 API 和 logback 的实现，确保项目使用统一的日志框架。
   • logback-classic 会自动绑定 SLF4J，并提供日志输出功能。

注意事项

• 排除范围： 仅影响当前依赖的传递依赖（即 httpclient），不会影响其他依赖路径中引入的 commons-logging。如果其他依赖也引入了 commons-logging，需逐一处理。
• 日志绑定一致性：确保项目中没有其他日志框架（如 log4j、java.util.logging）的依赖，否则仍可能导致冲突。
• 测试验证：迁移后需运行测试，确保日志输出正常，且无 NoClassDefFoundError 等异常。

2.2 解决版本冲突

在 Maven 项目中，当多个依赖引入了 同一库的不同版本 时，可能会导致版本冲突。为了处理这种冲突，我们可以使用  标签来排除某个依赖中的特定传递依赖，从而控制最终使用的版本。

示例场景：假设你的项目中引入了以下两个依赖：

1. com.example:library-a，它依赖：

   • com.fasterxml.jackson.core:jackson-databind:2.9.0

2. com.example:library-b，它依赖：

   • com.fasterxml.jackson.core:jackson-databind:2.10.0

由于 jackson-databind 是一个核心的 JSON 处理库，不同版本之间可能存在兼容性问题。Maven 默认会根据“最近优先”（nearest-wins）的依赖调解规则选择版本。假设 library-a 的路径比 library-b 更短，Maven 会默认使用 2.9.0 版本，这可能会导致你项目中实际需要的是 2.10.0 的功能或修复。

---

解决方案：使用  排除旧版本。我们可以在 library-a 的依赖中 排除掉它引入的 jackson-databind 2.9.0，这样就能确保整个项目都使用library-b引入的jackson-databind:2.10.0版本。

    
    
        com.example
        library-a
        1.0
        
            
                com.fasterxml.jackson.core
                jackson-databind
            
        
    

    
    
        com.example
        library-b
        1.0
    

或者，也可以显式声明我们需要的 jackson-databind 版本，Maven 会优先使用你显式声明的版本，从而解决版本冲突问题。

    
    
        com.example
        library-a
        1.0
    

    
    
        com.example
        library-b
        1.0
    

    
    
        com.fasterxml.jackson.core
        jackson-databind
        2.10.0
    

2.3 减少冗余依赖

移除不必要的传递依赖以简化构建。

场景：如果 spring-boot-starter-thymeleaf 依赖了 jdom2，但项目不需要它，可以排除：

    org.springframework.boot
    spring-boot-starter-thymeleaf
    2.5.0
    
        
            org.jdom
            jdom2