gradle和maven有啥用？分别有啥区别

Posted 2023-05-02

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

整个过程可以分成以下几个步骤：
编译源代码
运行单元测试和集成测试
执行静态代码分析、生成分析报告
创建发布版本
部署到目标环境
部署传递过程
执行冒烟测试和自动功能测试
如果你手工去执行每一个步骤无疑效率比较低而且容易出错，有了自动化构建你只需要自定义你的构建逻辑，剩下的事情交给工具去完成。

虽然两者都是项目工具，但是maven现在已经是行业标准，Gradle是后起之秀，很多人对他的了解都是从android studio中得到的，Gradle抛弃了Maven的基于XML的繁琐配置，众所周知XML的阅读体验比较差，对于机器来说虽然容易识别，但毕竟是由人去维护的。取而代之的是Gradle采用了领域特定语言Groovy的配置，大大简化了构建代码的行数，比如在Maven中你要引入一个依赖：

<properties>
<kaptcha.version>2.3</kaptcha.version>
</properties>
<dependencies>
<dependency>
<groupId>com.google.code.kaptcha</groupId>
<artifactId>kaptcha</artifactId>
<version>$kaptcha.version</version>
<classifier>jdk15</classifier>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</dependency>
</dependencies>

然后我将其转换成Gradle脚本，结果是惊人的：
dependencies
compile('org.springframework:spring-core:2.5.6')
compile('org.springframework:spring-beans:2.5.6')
compile('org.springframework:spring-context:2.5.6')
compile('com.google.code.kaptcha:kaptcha:2.3:jdk15')
testCompile('junit:junit:4.7')


注意配置从原来的28行缩减至7行！这还不算我省略的一些父POM配置。依赖的groupId、artifactId、 version，scope甚至是classfier，一点都不少。较之于Maven或者Ant的XML配置脚本，Gradle使用的Grovvy脚本杀伤力太大了，爱美之心，人皆有之，相比于七旬老妇松松垮垮的皱纹，大家肯定都喜欢少女紧致的脸蛋，XML就是那老妇的皱纹。

Gradle给我最大的有点是两点。其一是简洁，基于Groovy的紧凑脚本实在让人爱不释手，在表述意图方面也没有什么不清晰的地方。其二是灵活，各种在Maven中难以下手的事情，在Gradle就是小菜一碟，比如修改现有的构建生命周期，几行配置就完成了，同样的事情，在Maven中你必须编写一个插件，那对于一个刚入门的用户来说，没个一两天几乎是不可能完成的任务 参考技术A 　都是自动构建工具，但是完全是两个产品。Maven应该目前在Java企业级开发中占的比重比较大，Gradle是后起之秀，Google的Android Studio主推的就是Gradle。
　　Gralde吸收了Maven与Ant的优点，可以列举出很多。然而大量的实践与思考发现Maven相比于Gradle的不灵活，正是它的优点，避免了大量聪明的Build Engineer的出现。 参考技术B 1.面向未来，就目前的趋势而言，gradle或者maven正逐渐演化为一种标准。尤其是国际上。比如你去spring官网看demo，它们一般提供基于这两种的源码，还有android开发，很多流行的库，demo演示都是通过gradle搭建的，你不懂gradle就很难跟它们接轨。这显然是固步自封的表现。
2.极细的粒度，给你更大的发挥空间。你用eclipse的run的时候，你并不知道eclipse是怎么执行的，即便你知道，但是不可能轻易结合自己的代码逻辑。举个例子：我需要在run java项目的时候，把flex项目先编译好，放到web目录下。类似于这样，大部分情况下，光靠IDE自己的功能就力不从心了。 但是gradle给了你两个维度的机会，让你能干的更多。 第一 task的dependsOn、finalizedBy 让你可以把各种工作串行连接；第二 绝大多数插件是开源的，也就是用的不爽，你自己可以改，那样就更灵活了。当然这只是冰山一角。
3.协作，一个个build文件，描述项目依赖，插件，显然更具有一致性。再也不需要把那些讨厌的jar包提交到git了，要知道git里面存放二进制简直就是灾难。还有，甚至可以通过gradle跟，非程序员交流，比如你想让美工可以自己测试修改并在项目里面看最终效果。这时候你让她装个idea，估计她会很不情愿。但是，你可以通过gradle，告诉她，把素材覆盖到某某文件之后，只要在控制台来个gradle run，刷新页面就能看到效果了。（仅是个例子，可能不严谨）
4.布道groovy，gradle所使用的语言，也许groovy并不能算是jvm里的屠龙刀，但是也绝对可以算是一把锋利的匕首。相信我，作为一个java程序员，试着在代码中融入groovy，一定乐趣无限。尤其是还能用在android项目。

gradle依赖中的compile，testCompile和provided有啥区别

【中文标题】gradle依赖中的compile，testCompile和provided有啥区别

【英文标题】：what is the difference between compile, testCompile and provided in gradle dependencygradle依赖中的compile，testCompile和provided有什么区别

【发布时间】：2016-10-15 20:46:20

【问题描述】：

我正在使用 android studio 并且在项目结构中 -> 依赖项选项卡中我可以看到以下选项：

编译 提供 APK 测试编译 调试编译 发布编译

我的问题：gradle依赖中compile、testCompile和provided有什么区别

【问题讨论】：

Compile, Provided, APK - Android dependency scope的可能重复

【参考方案1】：

compile 是您构建应用程序所需的一组依赖项，而testCompile 是一组仅用于测试的依赖项。

例如查看build.gradle（取自here）

apply plugin: 'java'

repositories 
    mavenCentral()


dependencies 
    compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final'
    testCompile group: 'junit', name: 'junit', version: '4.+'

这指定需要hibernate-core 来构建您的代码，但junit（一个测试框架）仅用于测试。由于在运行时不需要它，所以它不会包含在发布的包中。

【讨论】：

抱歉吹毛求疵，但最后一行不应该是：因为它在运行时不需要，所以它不会包含在发布的包中。

【参考方案2】：

您应该阅读发行版随附的用户指南，或通过http://gradle.org/documentation/ 在线阅读。

简而言之，“compile”用于“main”代码的依赖项，“testCompile”用于测试类，“provided”用于在编译时使用但不存储在 WAR 文件中的依赖项（因为它们应该在您的 Web 容器中可用）。

以下帖子可能有相关信息：Compile, Provided, APK - Android dependency scope。

【讨论】：

问题被标记为 Android。 WAR 文件不适用