current situation
以前一直用的是maven，三套生命周期概念清晰，网上资料，文档众多，用起来还是很舒服的，得心应手
现在入职的公司，在使用Gradle，虽然我不怎么熟悉这个，但是还是强迫自己去学习
以下的体验，是基于maven来比较gradle的优劣
劣势
1. 中文资料
网上中文资料，大部分都是Android项目在使用gradle，而我是Java后端项目，部分特殊场景，中文资料是找不到的
2. 仓库
目前Java后端项目，很多第三方Jar包都是放在各种Maven私服上，在使用过程中，的确遇到了一些不尽人意的地方
比如，判断是否需要更新本地的Jar，gradle使用策略的是，去下载pom，判断最后更新时间来决定是否需要更新缓存，这个有时不能满足需求，直接判断jar不行吗？
还有，使用本地maven仓库就更蛋疼了，路径直接写死为c:/user/.m2/repository，没有地方修改这个配置（或者是我没有找到，哪位大佬知道告诉我，感激不尽）
当然后来我是通过配置本地仓库为maven的远程私服来解决的
优势
1. 去xml化
珍爱生命，远离xml，
现在好多技术都在有意识的不再使用xml，选用了yaml json等格式
Gradle 使用了Groovy
2. 完善的task体系
在Maven里，三套生命周期是固定的，执行哪个阶段，会自动将前面的所有阶段全部执行一遍(当然也有例外，比如跳过test)，
这么做好处是便于理解，过程自动化、标准化（如果说的不对，欢迎指出）
坏处也是显而易见的，就是不够自由，
比如，我以前经常想只单独执行某一个阶段，或者跳过某一个阶段，但是办不到，令一些脑洞大开的想法不能付诸实践
有点遗憾
Gradle这方面就支持的比较好了，如果继续使用Maven这一套生命周期体系，是可以的，
比如执行build，也会执行assemble 和test
跳过，使用-x test
3. gradlew
有一个很有意思的task，叫做init，会自动生成一些配置和脚本
脚本有两个，gradlew.bat是在Windows上使用的，gradlew是在Linux上使用的
这个脚本的作用就是，别人下载了工程之后，不用自己去进行安装Gradle、配置环境变量等操作，执行这个脚本就可以了
免去了这些繁琐步骤，非常有想法的解决方案
网友评论