Maven中optional的作用

发布于:2025-09-12 ⋅ 阅读:(16) ⋅ 点赞:(0)

目的:

  • 控制依赖传递 :将依赖标记为可选,这样当其他模块依赖common-component时,不会自动继承Elasticsearch依赖。这遵循了"依赖最小化"原则,避免不必要的库被引入到不需要它们的模块中。
  • 模块化设计 :jetlinks框架采用模块化设计,common-component作为通用基础组件,不应该强制所有使用它的模块都引入Elasticsearch相关功能。通过optional配置,实现了功能的可选性和灵活性。
  • 避免版本冲突 :防止多个模块引入不同版本的Elasticsearch库导致冲突,让实际需要Elasticsearch的模块自行管理其依赖版本。

示例:

common 模块有这么个依赖

<dependency>
	<groupId>org.elasticsearch</groupId>
    <artifactId>elasticsearch</artifactId>
    <optional>true</optional>
</dependency>

模块A引入了 common模块

  <dependency>
     <groupId>org.jetlinks.pro</groupId>
     <artifactId>common-component</artifactId>
     <version>${project.version}</version>
 </dependency>

此时 common的 elasticsearch 依赖不会传递给 A,也就是说 A 是没有 elasticsearch 依赖的,想要这个依赖需要自己单独再引入 elasticsearch,如果想要继承 common 的 elasticsearch,那就去掉 optional 标签即可

【另一种情况】

common 模块的 elasticsearch 去掉了 optional 标签,模块 A 引入了 common,同时模块A自己又单独引入了 elasticsearch ,此时会发生依赖冲突吗?

  • 如果两处的 elasticsearch 版本一致,则不会,maven会优先使用模块A自己的 elasticsearch 依赖
  • 如果两处的版本不一致,则会发生依赖冲突

如果发生了冲突,又不能修改 common 的 pom 文件,我们想用自己引入的依赖,可以选择在引入 common 时排除 common 模块的elasticsearch

<dependency>
     <groupId>org.jetlinks.pro</groupId>
     <artifactId>common-component</artifactId>
     <version>${project.version}</version>
     <exclusions>
         <!-- 排除common-component中的r2dbc-spi依赖,使用本模块中直接声明的版本 -->
         <exclusion>
             <groupId>org.elasticsearch</groupId>
    		 <artifactId>elasticsearch</artifactId>
         </exclusion>
     </exclusions>
 </dependency>

网站公告

今日签到

点亮在社区的每一天
去签到