Java多项目依赖管理

#Java #Maven #依赖

maven依赖继承与聚合

见官方文档

spring的依赖管理

以spring-cloud为例进行说明

spring-cloud-dependencies Hoxton.SR6 定义spring-cloud中各个组件的版本. 组件的版本各不一致. 用于规定各组件之间的版本兼容性.

组件内 组件以及组件的子模块的版本完全统一, 有任何改动都会导致整个组件的版本递增. 也会定义组件的外部依赖的版本号, 对其统一管理.

我使用的依赖管理

与spring的依赖管理类似, 也有不同之处.

每个组件的外部依赖版本, 不是在组件内定义, 而是由base-pom统一定义. 这样做的好处是,由于组件之间存在依赖,且组件的外部依赖可能冲突,为了避免冲突,外部依赖的版本统一管理.

版本升级策略

  • 版本号 大版本.小版本.修复版本 大版本:当组件出现重大迭代,会增加大版本号. 小版本:当组件新增feature,会增加小版本号. 修复版本:当修复缺陷,会增加修复版本号.

  • 升级策略

  1. 定义新的开发版本, 如1.23.45-SNAPSHOT. 版本应用到组件内所有模块, 并提交代码.
  2. 修改代码,并提交代码.
  3. 代码通过测试,可以发布时, 修改版本为release. 如1.23.45. 版本应用到组件内所有模块. 并提交代码.
  4. 发布组件
  5. 定义新的开发版本, 如1.23.46-SNAPSHOT 或 1.24.0-SNAPSHOT

题外:微服务中monoRepo与multiRepo如何选择.

monorepo: 单一代码库,所有项目都在这一个代码库中. multiRepo: 多代码库, 每个项目一个代码库.

首先明确一点,无论团队大小, 既然是微服务, 那肯定会为每个服务指定负责人, 而不会交错负责.

multiRepo优点:

  1. 每个人只需要关注自己负责的服务的代码.
  2. 小团队,可以避免团队内有人随意修改他人负责的代码. 大团队,只开负责的代码仓库的权限.
  3. IDEA 中只打开自己负责的代码, 搜索代码什么的都很方便.
  4. CI/CD 方便
  5. 版本管理方便, 减少代码冲突.

multiRepo缺点:

  1. 需要搭建 maven 私仓, 对所有的公共技术模块进行严格的版本管理, 在 base-pom 中对版本进行统一管理.
  2. 降低开发者维护公共技术模块的意愿. 因为修改公共模块,哪怕只修改一行代码,都需要升级版本, 然后对很多 git 仓库进行代码提交. 服务发布前,还要把相关模块的版本从 SNAPSHOT 改为 RELEASE, 有点麻烦.

multiRepo的优点就是monoRepo的缺点.

  • 在微服务架构中, 每个服务有专门的负责人, multiRepo更合适. 权限控制更全面.
  • 团队人越多, 代码冲突的可能性越大. multiRepo可以大大减少该情况.
  • 在团队人员素质参差不齐的情况下, monoRepo有发展为分布式单体的倾向, 各项目之间以及公共模块会产生大量耦合.
  • 从管理的角度, multiRepo比monoRepo有更强的可控性.

我个人建议:除了"团队人非常少,项目周期非常短", 其他情况应使用multiRepo.