共计 5050 个字符，预计需要花费 13 分钟才能阅读完成。
置信应用 Java 的同学都用过 Maven，这是一个十分经典好用的我的项目构建工具。然而如果你常常应用 Maven，可能会发现 Maven 有一些中央用的让人不太难受：
- 一来 Maven 的配置文件是 XML 格局的，如果你的我的项目依赖的包比拟多，那么 XML 文件就会变得十分十分长；
- 二来 XML 文件不太灵便，如果你须要在构建过程中增加一些自定义逻辑，搞起来十分麻烦；
- 第三就是 Maven 十分的稳固，然而绝对的就是对新版 java 反对有余，哪怕就是为了编译 java11，也须要更新内置的 Maven 插件。
如果你对 Maven 的这些毛病也有所感触，筹备尝试其余的构建工具，那么你能够试试 gradle，这是一个全新的 java 构建工具，解决了 Maven 的一些痛点。
换上 gradle
不得不抵赖的一件事件就是 gradle 作为一个新兴的工具曾经有了宽泛的利用。spring 等我的项目曾经从 Maven 切换到了 gradle。开发安卓程序也只反对 gradle 了。因而不论是否当初须要将我的项目从 maven 切换到 gradle，然而至多学习 gradle 是一件必要的事件。
装置 gradle
最传统的装置办法就是去 gradle 官网下载二进制包，解压，而后将门路增加到环境变量中。如果你没什么其余需要，能够应用这种装置形式。然而，gradle 是一个十分新潮的我的项目，每隔几个月就会公布一个新版本，这种形式可能跟不上 gradle 的更新速度。
所以我更加举荐应用包管理器来装置 gradle。如果你应用 linux 零碎，那么不用多说。如果你应用 Windows 零碎，我举荐应用 scoop 包管理器来装置 gradle。它装置不便，而且应用 SHIM 目录来治理环境变量，在各种工具中配置 gradle 也很不便。
当然，如果你齐全不喜爱装置这么多乌七八糟的货色，那也能够应用 gradle。gradle 提供了一个名为 gradle wrapper 的工具，能够在没有装置 gradle 的状况下应用 gradle。好吧，其实它就是个脚本文件，当你运行 wrapper 脚本的时候，如果脚本发现你电脑里没有 gradle，就会主动替你下载安装一个。当初甚至还呈现了 Maven wrapper，也是个脚本文件，能够主动装置 Maven。
之前置信一些敌人据说过 gradle，而后尝试应用它，后果因为速度太慢，最初放弃了。之前我也因为 gradle 的速度，放弃了它一段时间。不过当初应用 gradle 的话会不便很多。gradle 官网在中国开设了，CDN，应用 gradle wrapper 的时候下载速度十分快。能够说当初是一个学习应用 gradle 的好时候。
应用 gradle wrapper
这里我应用的 IDEA 来创立和应用 gradle 我的项目。
IDEA 默认就会应用 gradle wrapper 来创立我的项目，所以无需装置 gradle 也能够失常运行。这时候我的项目构造应该相似下图所示，应用 Maven 的同学应该比拟相熟，因为这和 Maven 的我的项目构造简直完全一致。gradle 文件夹和 gradlew 那几个文件就是 gradle wrapper 的文件，而.gradle 后缀名的文件正是 gradle 的配置文件，对应于 Maven 的 pom.xml。
gradle wrapper 的长处之一就是能够自定义下载的 gradle 的版本，如果是团队合作的话，这个性能就十分不便，简略设置即可对立团队的构建工具版本。这里我就设定成目前最新的 gradle 6.4. 默认下载安装的是 bin 版，仅蕴含二进制。如果你应用 IDEA 的话，它会举荐下载 all 版，蕴含源代码，这样 IDEA 就能够剖析源代码，提供更加准确的 gradle 脚本反对。
# 依赖治理
上面来看看 gradle 的依赖治理性能，这也算是咱们应用构建工具的次要目标之一了。这点也是 gradle 相较 maven 的劣势之一了。相较于 maven 一大串的 XML 配置，gradle 的依赖项仅需一行。
dependencies {
testImplementation 'junit:junit:4.13'
implementation 'com.google.code.gson:gson:2.8.6'
}这里举荐一下 Jetbrains 的 package search 网站，是寻找 maven 和 gradle 依赖包的最佳网站，能够十分轻松的搜寻和应用依赖项。
gradle 依赖的粒度管制相较于 Maven 也更加精密，maven 只有 compile、provided、test、runtime 四种 scope，而 gradle 有以下几种 scope：
1、implementation，默认的 scope。implementation 的作用域会让依赖在编译和运行时均蕴含在内，然而不会裸露在类库使用者的编译时。举例，如果咱们的类库蕴含了 gson，那么其他人应用咱们的类库时，编译时不会呈现 gson 的依赖。
2、api，和 implementation 相似，都是编译和运行时都可见的依赖。然而 api 容许咱们将本人类库的依赖裸露给咱们类库的使用者。
3、compileOnly 和 runtimeOnly，这两种顾名思义，一种只在编译时可见，一种只在运行时可见。而 runtimeOnly 和 Maven 的 provided 比拟靠近。
4、testImplementation，这种依赖在测试编译时和运行时可见，相似于 Maven 的 test 作用域。
5、testCompileOnly 和 testRuntimeOnly，这两种相似于 compileOnly 和 runtimeOnly，然而作用于测试编译时和运行时。
通过简短精悍的依赖配置和多种多样的作用与抉择，Gradle 能够为咱们提供比 Maven 更加优良的依赖治理性能。
gradle 的工作和插件
gradle 的配置文件是一个 groovy 脚本文件，在其中咱们能够以编程形式自定义一些构建工作。因为应用了编程形式，所以这带给了咱们极大的灵活性和便捷性。打个比方，当初有个需要，要在打包出 jar 的时候顺便看看 jar 文件的大小。在 gradle 中仅需在构建脚本中编写几行代码即可。而在 Maven 中则须要编写 Maven 插件，复杂程度齐全不在一个程度。
当然，Maven 倒退到当初，曾经存在了大量的插件，提供了各式各样的性能能够应用。然而在灵活性方面还是无奈和 Gradle 相比。而且 Gradle 也有插件性能，当初倒退也非常迅猛，存在了大量十分好用的插件，例如 gretty 插件。gretty 原来是社区插件，起初被官网排汇为官网插件，能够在 Tomcat 和 jetty 服务器上运行 web 我的项目，比 Maven 的相干插件性能都弱小。
尽管 gradle 能够非常灵活的编写自定义脚本工作，然而其实个别状况下咱们不须要编写构建脚本，利用现有的插件和工作即可实现相干性能。在 IDEA 里，也能够轻松的查看以后 gradle 我的项目中有多少工作，根本工作如 build、test 等 Maven 和 Gradle 都是相通的。
配置镜像
Maven 官网仓库的下载速度十分慢，所以个别咱们要配置国内的镜像源。gradle 在这方面和 Maven 齐全兼容，因而只需略微配置一下镜像源，即可应用 Maven 的镜像。如果你用 gradle 构建过我的项目，应该就能够在用户目录的.gradle 文件夹下看到 gradle 的相干配置和缓存。
之前 wrapper 下载的 gradle 也寄存在该文件夹下，地位是 wrapper/dists。
而依赖的本地缓存在 caches\modules-2\files-2.1 文件夹下。目录构造和 Maven 的本地缓存相似，都是包名 + 版本号的形式，然而 gradle 的目录构造最初一层和 Maven 不同，这导致它们无奈共用本地缓存。
言归正传，在 gradle 中配置下载镜像须要在.gradle 文件夹中间接新建一个 init.gradle 初始化脚本，脚本文件内容如下。这样一来，gradle 下载镜像的时候就会应用这里配置的镜像源下载，速度会快很多。再加上 gradle wrapper 在中国设置了 CDN，当初应用 gradle 的速度应该会很快。
allprojects {
repositories {
maven {url https: //maven.aliyun.com/repository/public}
maven {url https: //maven.aliyun.com/repository/jcenter}
maven {url https: //maven.aliyun.com/repository/spring}
maven {url https: //maven.aliyun.com/repository/spring-plugin}
maven {url https: //maven.aliyun.com/repository/gradle-plugin}
maven {url https: //maven.aliyun.com/repository/google}
maven {url https: //maven.aliyun.com/repository/grails-core}
maven {url https: //maven.aliyun.com/repository/apache-snapshots}
}
}当然，如果你有代理的话，其实我举荐你间接为 gradle 设置全局代理。因为 gradle 脚本切实是太灵便了，有些脚本中可能依赖了 github 或者其余中央的近程脚本。这时候下面设置的下载镜像源就不论用了。
所以有条件还是罗唆间接应用全局代理比拟好。设置形式很简略，在.gradle 文件夹中新建 gradle.properties 文件，内容如下。两头几行即是设置代理的配置项。当然其余几行我也倡议你设置一下，把 gradle 运行时的文件编码设置为 UTF8，减少跨平台兼容性。
org.gradle.jvmargs=-Xmx4g -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8systemProp.http.proxyHost=127.0.0.1systemProp.http.proxyPort=10800systemProp.https.proxyHost=127.0.0.1systemProp.https.proxyPort=10800systemProp.file.encoding=UTF-8org.gradle.warning.mode=all为什么应用 gradle？
看到这里，你应该对 gradle 有了根本的理解，也能够将其用于你的我的项目之中。然而如果你 Maven 曾经十分相熟了，可能不太违心应用 gradle，因为貌似没有必要。然而既然 gradle 呈现了，就阐明有很多人对 Maven 还是有肯定的意见。因而在这里我来总结一下 gradle 相比 maven 的劣势。
首先第一点也就是最重要的一点就是速度。gradle 应用构建缓存、守护过程等形式进步编译速度。后果就是 gradle 的编译速度要远超 maven，均匀编译速度比 Maven 快好几倍，而且我的项目越大，这个差距就越显著。
第二点就是灵活性，gradle 要比 Maven 灵便太多，尽管有时候灵便并不是一件好事件。然而大部分状况下，灵便一点能够极大的不便咱们。Maven 死板的 XML 文件形式做起事件来十分麻烦。很多 Maven 我的项目都通过执行内部脚本的形式来实现一些须要灵活性的工作。而在 gradle 中配置文件就是构建脚本，构建脚本就是编程语言（groovy 编程语言），齐全能够自力更生，无需内部脚本。
第三点就是 gradle DSL 带来的简洁性。实现同样的性能，gradle 脚本的长度要远远短于 maven 配置文件的长度。尽管很多人都说 XML 保护起来不麻烦，然而我感觉，保护一个光是依赖就有几百行的 XML 文件，不见得就比 gradle 脚本简略。
兴许是因为我下面说的起因，兴许有其余起因，不得不抵赖的一件事件就是 gradle 作为一个新兴的工具曾经有了宽泛的利用。spring 等我的项目曾经从 Maven 切换到了 gradle。开发安卓程序也只反对 gradle 了。因而不论是否当初须要将我的项目从 maven 切换到 gradle，然而至多学习 gradle 是一件必要的事件。
起源：toutiao.com/i6824937779193971207
