置信应用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