gradle和maven有什么用？有什么区别？

Gradle和Maven都是自动项目构建工具。编译源代码只是整个过程的一个方面。更重要的是，您必须将您的软件发布到生产环境中，以产生商业价值。因此，你必须运行测试，构建发行版，分析代码质量，甚至为不同的目标环境提供不同的版本，然后进行部署。有必要使整个过程自动化。

整个过程可分为以下步骤:

编译源代码

运行单元测试和集成测试

执行静态代码分析并生成分析报告。

创建发布版本

部署到目标环境

部署交付流程

进行烟雾测试和自动功能测试。

如果手动执行每一步，无疑效率低下且容易出错。有了自动化构造，您只需要定制您的构造逻辑，剩下的交给工具。

虽然两者都是项目工具，但maven现在是行业标准，Gradle是后起之秀。很多人都是从安卓工作室认识他的。Gradle抛弃了Maven繁琐的基于XML的配置。众所周知，XML的阅读体验很差。虽然机器很容易识别，但毕竟是靠人来维护的。而是采用了特定领域语言Groovy的配置，大大简化了构建代码的行数。例如，在Maven中，您需要引入一个依赖项:

& lt属性& gt

& ltkaptcha.version & gt2.3 & lt/kapt cha . version & gt；

& lt/properties & gt；

& lt依赖关系& gt

& lt依赖性& gt

& ltgroupId & gtcom . Google . code . kapt cha & lt；/groupId & gt；

& ltartifactId & gtkaptcha & lt/artifact id & gt；

& lt版本& gt$ { kaptcha.version } & lt/version & gt；

& lt分类器& gtJDK 15 & lt；/classifier & gt；

& lt/dependency & gt；

& lt依赖性& gt

& ltgroupId & gtorg.springframework & lt/groupId & gt；

& ltartifactId & gt弹簧芯& lt/artifact id & gt；

& lt/dependency & gt；

& lt依赖性& gt

& ltgroupId & gtorg.springframework & lt/groupId & gt；

& ltartifactId & gt春豆& lt/artifact id & gt；

& lt/dependency & gt；

& lt依赖性& gt

& ltgroupId & gtorg.springframework & lt/groupId & gt；

& ltartifactId & gtspring-context</artifact id & gt；

& lt/dependency & gt；

& lt依赖性& gt

& ltgroupId & gtjunit & lt/groupId & gt；

& ltartifactId & gtjunit & lt/artifact id & gt；

& lt/dependency & gt；

& lt/dependencies & gt；

然后我把它转换成Gradle脚本，结果很惊人:

依赖关系{

编译(' org . spring framework:spring-core:2 . 5 . 6 ')

编译(' org . spring framework:spring-beans:2 . 5 . 6 ')

编译(' org . spring framework:spring-context:2 . 5 . 6 ')

编译(' com . Google . code . kapt cha:kapt cha:2.3:JDK 15 ')

test compile(“JUnit:JUnit:4.7”)

}

注意配置从28线减少到了7线！这还不算我省略的一些父POM配置。依赖的groupId，artifactId，版本，作用域甚至分类器，一点也不少。相比Maven或者Ant的XML配置脚本，Gradle用的Grovvy脚本杀伤力太大，爱美之心人皆有之。比起70岁老太太的松弛皱纹，大家肯定更喜欢姑娘紧绷的脸，XML就是那个老太太的皱纹。

格雷尔给我的最大收获是两分。

一个是简洁。基于Groovy的紧凑脚本确实让人爱不释手，在表达意图上没有什么不清楚的。

第二是灵活性。各种在Maven中很难做到的事情，在Gradle中都是小菜一碟，比如修改现有的build生命周期，完成几行配置。同样，你必须用Maven写一个插件，这对于一个新手用户来说，一两天几乎是不可能的。