应该选择Maven还是Gradle?

推荐 源码巴士 48浏览

阅读本文前,请至少知道什么是Maven和Gradle,并对其有一定的使用基础。

基本概念与约定

  • Maven
    • 项目结构/依赖由pom.xml定义
    • 生产代码存放在src/main/java下
    • 测试代码存放在src/test/java下
Maven项目结构.png
    • 项目结构/依赖由build.gradle定义
    • 生产代码存放在src/main/java下
    • 测试代码存放在src/test/java下
    Gradle项目结构.png
  • Gradle的出现比Maven晚,而且深受Maven的影响,但又觉得Maven的配置过于啰嗦,采用代码的方式进行声明依赖

构建流程和生命周期

  • Maven
    • 三个标准的生命周期(lifecycle)
    • 最小的运行单元是目标(goal)
    • 插件可以把自己的目标绑定在生命周期的某个阶段(phase)上
  • Gradle
    • 没有显示的生命周期
    • 最小的运行单元是任务(task),任务之间可以相互依赖
    • 可以动态地创建任务

包管理和传递性依赖

  • Maven
    • 一个包由groupId/artifactId/version确定唯一坐标
    • 包来源于中央仓库
    • 传递性依赖
      • 当某个包的的使用依赖于其他包时,Maven会自动导入所有的依赖包
  • Gradle
    • 使用Ivy的构件系统,是Maven的构件系统的超集

      Ant ivy是一个比Maven仓库更加广阔的仓库

    • 与Maven仓库兼容
    • Maven依赖解调遵循两个原则,路径最近原则以及定义顺序原则出现依赖冲突时
  • Mavenc依赖冲突.png
  • Gradle的冲突解析则是选用新的版本(新的版本一般都会向下兼容)

总结:

    • 稳定可靠,插件众多。(这么多年版本一直维持在3.XX,而且很久才发布一次小更新,说明他稳定且bug较少)
    Maven版本.png
  • 略显啰嗦,自定义逻辑较麻烦(Maven使用xml的方式进行配置,xml的劣势繁琐就会体现在Maven上)
Maven配置.png
  • 大型项目会逐渐遇到性能问题
    • 使用Maven构建的项目都会经过几个生命流程,内部没有缓存机制,项目越来越大重新构建所花费的时间也就越长。
  • 由于Maven的开发基本靠社区支持,没有更多的资金用于继续开发维护Maven,导致开发基本停泻。
    • Gradle内部存在缓存机制(当文件输入和输出都没改变的情况下,认为这就是没变的代码,直接进行输出。但当你改变的依赖包版本,它有时并没更新,也是缓存机制的问题),相比会快些。
    • 开发活跃,版本太多Gradle采用代码逻辑的方式进行构建,使得它能更加的灵活。
      Gradle配置.png
  • Gradle版本.png
    • 从上图不难看出Gradle版本更新很快(背后资金的支持)。
    • 更新版本过快会让使用者学习成本变高
    • 不可避免的兼容性问题
    • 新版本特性和功能带来的便利
  • So 各有各的优势,谁也不能说谁完美,各有千秋。

怎么选择?

  • 首先得看老板啊
  • 其次所处的团队更加熟悉哪个工具
  • 我是否必须要依赖某个工具
    • 我的构建环境只支持Maven/Gradle
    • 我需要的插件只有Maven/Gradle
  • 如果以上这些问题都不存在的话,Gradle这种通过编写代码的方式构建项目,更加现代化。

转载请注明:源码巴士 » 应该选择Maven还是Gradle?