我们公司有几个项目用过gradle，但大部分还是用maven，而且以后估计还会用maven，为什么呢？就是因为gradle的杀手锏：脚本太强大了。
早期的构建都是脚本化的，用sh或者bat来组合编译，打包，部署等过程，后来进化到xml描述的ant工具，但还是可以写很多自定义的任务，调用本地命令打包，各种任务组合，跟bat差不多，它们的共同特点就是：灵活！可以指定自己的依赖路径，个性化打包过程。直到后来，maven出现了，只能通过不同的archtype来构建不同的项目，而每种项目类型的项目工程目录是固定的，如果没有问题，一个package命令就可以了，不再有个性化的配置（自己写mojo例外），约定优于配置是它的哲学！而且，你只要理解pom.xml基本配置即可。
gradle结合了maven的优点，同时又保留了脚本调用的特点，很多时候给人太多选择和机会，反而会将项目（特别是大型项目）的构建配置复杂化。导致新人很难掌握，其dsl语法是简化略的groovy调用，有时候不了解groovy语言及其语法，很难理解和写出好的构建脚本，学习成本高。
评论0
加载中...
第一到底是不是gradle比maven少，这个问题我没看过数据不知道实际情况。但是从历史角度和目前现状来看maven日常接触的是要多一些，毕竟技术这玩意就是一工具，用的熟练顺手就好，没必要一味求新。个人浅见
评论0
加载中...
用的多和少是量级上的。 gradle后于maven出现，显然是挑战者身份的。大多老项目是否愿意替换成gradle阻力很大。 所以量上看不那么能说明问题。
目前新项目是否一定选择gradle？相信大家都没定论。可见gradle作为继任者的确没有那么流行。 究其原因，可能有2点
1，配置表示语言问题。 项目表示类工具是一定要和项目解耦，因此注定了是个静态配置。 maven用的老牌xml表示语言，虽然啰嗦，但是没什么违和感，很容易理解。 反观gradle为了简洁，失去了表示直观性。
2，配置隔离原则。gradle用灵活脚本能力，不但增加理解维护成本，还打破了配置和实现的边界。配置是黑盒子，隔离理解成本的，不应该提供任何执行和互操作能力。
这个是gradle的不好的地方，而减少构建时间已经不是关键改进了。另外一个反例是sbt，用过的人相信都是一言难尽。
评论0
加载中...
我司有个项目用kotlin和java混写的，gradle编译，我从win换到mac，还是一直报gradle问题，最后我直接离职了。
评论0
加载中...
gradle现在是android studio的标配构建框架怎么说用得少呢？
android开发者目前乌泱乌泱一大片，而不会使用gradle基本没法玩了，所以用的人很多的。
maven的使用者，主要还是是以前老的web开发者，虽然gradle强大得多，但由于学习成本的关系(gradle学习并不轻松)，很多人还在坚持。
评论0
加载中...
Gradle 使用真的比 Maven 的人要少吗？
Github 文件名搜索的参数数据：
图1：是在 GitHub 中搜索 build.gradle 文件名的匹配数量有 970 万
图2：是在 GitHub 中搜索 pom.xml 文件名的匹配数量有 930 万
当然这一组数据仅仅只能作为参考，并不完全准确，不过我们也能从中看出使用 Gradle 的人并不少，相反很多。
可能是题主身边使用的比较少，造成这种原因可能主要原因有两点。
相反对于熟悉 Gradle 的人来说，他们会更习惯 Gradle 的工作方式，因为在配置上它比 Maven 要简洁。配置比 Maven 简洁这并不是 Gradle 最大的优势，而是 Automate Everything（自动化一切） 实现上要比 Maven 容易的多，这才是我真正喜欢 Gradle 的理由。
比如：
根据环境自动化配置，因为 *.gradle 文件其实就是 groovy 所以可以在构建脚本中直接就是使用 groovy 编码。不仅支持条件语句，还直接使用 java、groovy 的 API，比如 System.getenv 获取系统环境变量然后根据值做一些操作就比 Maven 要容易很多。
repositories {
mavenLocal()
def aliyunEnabled = System.getenv("GITHUB_ACTIONS") == null
if (aliyunEnabled) {
maven {
url = "https://maven.aliyun.com/nexus/content/groups/public/"
}
}
mavenCentral()
}
在国内访问 Maven 的中央仓库下载依赖效率不高，所以采用 Aliyun 提供的镜像仓库速度会快得多，但本人一直喜欢白漂 ???? 使用免费的 GITHUB_ACTIONS，在 GITHUB_ACTIONS 构建时访问ucloud云镜像速度很慢，所以就有了上一段逻辑。如果你使用 Maven 的话可能需要使用 profile 来区分，在构建命令上加上 profile 相关的参数，或者使用 settings.xml 的方式去配置镜像，但是多人协作时每个人都需要配置。而在使用 Gradle 时就可以轻易的做到一次配置到处运行，不需要额外配置，不需要额外命令参数实现这一自动化构建。
更多的就不在举例了，选择一项工具，可能是客观的原因，也可能是主观原因。当然我觉得更多的是在你身边，团队有人带头去做这个事情。
同时也期望更多的人能使用 Gradle 来简化你的工作，让工作变得更加轻松，Automate Everything。
评论0
加载中...
gradle大型项目配置比较好一点，简洁；
maven 相对来说比较冗余，但gradle还是基于maven 的，没有多大的改变。习惯问题。
评论0
加载中...0
回答0
回答10
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答
