为什么 Java 的包管理器都这么复杂？

[SystemLight]

1. 反观 node 的 npm，python 的 pip，.net 的 nuget 哪一个不是一个命令就安装好的依赖包
2. 为何 java 的 gradle 或者 maven 都没有这样的特性，还需要自己去配置文件而不是命令安装，而且 gradle 用的 groovy 闭包写法外行看了完全懵逼，而 npm 的 package.json 用 json 语法易读相当高
3. Java 包管理方案难道就不能简单一点，为何要搞得如此复杂，难道不应该是花费更多精力处理业务逻辑么，包管理搞得如此复杂还要去配置这个东西

[matrix67]

翻页

[young1lin]

Maven 其实挺简单的啊，你花 30 分钟学个教程，就能搞懂了，怎么叫复杂了呢？常用的就那几个东西啊，Gradle 表面上看起来非常精简，但是要自定义一些内容的时候就比较麻烦了，还有处理版本问题，exclude 还是挺好用的。而且 XML 这种格式，它不理解起来容易吗？

[EIJAM]

@superrichman 怕读英文的人何苦做开发呢？

[shellic]

别的不知道，反正我觉得最难用的当属 npm 没有之一，pip 、composer 、maven 比起 npm 简直就是清流

[Magentaize]

虽然 npm 和 pip 不能和 gradle 相比，但是 dotnet 这边的 nuget 和 msbuild 很好用啊

[DefoliationM]

java 不就这样 又臭又长

[superrichman]

@EIJAM 我见过的很多程序员是没有很好的英文功底的，也不会阅读大段的英文文档，但是人家还是在做开发。世界就是这样，各种各样的人都有。

[xarthur]

@hantsy 你用插件和第一方支持比就没什么意思了……

[xarthur]

@hantsy 而且 build.gradle 严格意义上也不是一个配置文件，是个完整的脚本。只是 DSL 的特性让它看上去像是个配置文件……

[mritd]

你说别的我信，但是 npm 就别来扯淡了好么，最烂的就是这玩意

[johnsona]

各位大神不知萌新苦，有没有什么好的 java 教程推荐，说看英文文档的速速退去

[Jirajine]

@sampeng gradle 难用的原因主要是因为它是 language agnostic 的，而 npm/pip/cargo 等则是为某个语言专门设计的（脚本语言不需要编译，因而安装依赖等同于链接，可以看作是“构建”）。
cargo 算是比较现代的构建 /依赖管理工具了。编译慢是 rust 的原因，ci/cd 最好配上 sccache 。有 samver 和 mangling，找不到兼容版本也可以共存，多数情况下都是无痛的。
另外 gradle 工具本身，兼容性糟糕（一大堆不同版本），groovy dsl 难用，作用不大的 c/s 架构（会导致多个 daemon 进程、文件锁之类的坑）。当然这些也在改善，等什么时候默认用 kts 、不用 gradlew，那体验还会好一点。

[walpurgis]

楼主说的其实是 maven 和 gradle 的使用体验差，并不是管理依赖的稳定性，这点我是同意的
在入门的时候感受明显，别家照着教程敲一行命令就搞定了，java 给一段配置不知道粘贴在哪，每次起新项目就去翻老项目的 pom 当模板

[taoboli]

还有吹 npm 的？凡是在 Windows 下装过 node-gyp 就知道什么是狗屎般的体验。
就前几天项目有个 node-gyp 依赖，npm 要对其进行编译安装，python3 和 vs2019 都不识别，硬是要在 2021 年装一个 python 2 和 vs2015 build tools 才能顺利编译、安装。

[Perry]

什么都不说上来就喷 Java 的，要没就是没学过计算机科学，要么就是双商有问题。

[coolesting]

npm 上手快，易用， 但目前包管理方面绝对是坑货。

gradle，上手慢， 复杂。 但稳重，有踏实感。

[cus]

Python 一个项目一个 venv…

[hantsy]

@taoboli Python3,VS2019 在 Nodejs 15 以后是可以用的。gyp 真正一朵奇葩。依赖 gyp 太多，典型的 Node sass 很多架框都用了，基本上无法避开。

[hantsy]

@xarthur 说 build.gradle 是脚本太牵强了，只是它可以嵌入自定义的脚本而已，但是 Gradle 的每版本的支持格式是非常严格的定义，生命周期也与 Maven 类似。不要拿 DSL 说事，Gradle 中的 Groovy 和 Kotlin 的 DSL 有严格语法的，与 XML，YAML 类似，对大多数人来讲，只是换一种写法而已。

Gradle 最初出来的时候，有人给出一个定位，Gradle 就是 Maven+Ant 脚本， 有固定一套生命周期，支持自定的脚本，这个基本上说明了 Gradle 定位。这些年基本上没什么变化，没有脱离。

至于上面有提到 Gradle 的语言中立，不仅仅 Jvm 语言，基本可以说上自己一厢情愿的意淫吧，这基本和 MSBuild 支持 C/C#之外的语言一样。

[blless]

我大 go module 终于扬眉吐气了，我个人宣布 go module 天下第一！
前面说 go 打包镜像慢的，我们公司自己各种 goproxy，大项目是需要固化依赖到 vendor 的，根本不需要下载资源。

[Actrace]

没有包管理其实就是最好的包管理。

想想以前 PHP 为什么能流行起来，就是因为它把绝大多数需要用到的工具都打包好了。
虽然现在又有人作妖搞什么 composer，不过不影响它依旧好用的特性。

[siweipancc]

作为一个强迫症，每次拿到库都是先撸源代码，然后被前端大姐嫌弃，也经常被后端组长吐槽浪费时间。（最近修了一大堆前后端的祖传 bug 之后就没挨喷了）。跑题了不好意思

[gaoshiba]

最烦 java if(xx!=null)xx.close()，为什么就不能直接帮我在方法里判断呢。

[sheeta]

@gaoshiba 哈哈，现在稍微好点了，有 try with resource

[gaoshiba]

@sheeta 哦吼，学到新东西了。早上才把我上面提到的那些代码全部删了，修改实现方式，改成了不需要 close 的方法，hh

[momocraft]

maven 学会一次能用十年，真的比每十个月重新学习 webpack 更复杂吗

[sutra]

多学习，可以不那么狭隘。

[NXzCH8fP20468ML5]

我会 msbuild，cargo，npm，pip 不会 maven，go mod 怎么办

[EminemW]

@blless 想问一下没有 pkg.go.dev 之前，go 的包怎么查版本号

[mogg]

@EminemW git branch / tag

[mogg]

go module 是真的舒服，一方面 go 的编译是真的快，另一方面源码编译让 go 作为编译型语言还不用考虑跨平台的问题，自定义功能~~抄代码~~也方便

[xarthur]

@hantsy 不牵强啊……
官方说的很清楚了
"We call this build.gradle file a build script, although strictly speaking it is a build configuration script, as we will see later. The build script defines a project and its tasks.

To try this out, create the following build script named build.gradle."
https://docs.gradle.org/current/userguide/tutorial_using_tasks.html
而且在具体运行的时候也是和脚本一样一行一行执行的。

[halk]

前端代码写得少，但公司的前端项目总是编译失败，各种包下载不下来。。

[Aoang]

提一下 Golang 的依赖管理。

在过去，Golang 没有官方的 go mod，那时候依赖管理都是一塌糊涂，然后渐渐的出现了很多第三方包管理器，但是没有一个好用的。
除开包管理器，也有人做了版本管理来控制版本，以此来凑活，gopkg.in 因此诞生，用这个做版本管理的库还不少，比如 go yaml 等等。

go mod 出来之后，一切都变好了吗？然而并没有，只是大部分情况下变好了。
它对库的规范很严格，很多库因为之前没有版本管理，都使用的一些骚操作来实现版本管理。比如，用 v1 v2 这种目录的形式来管理版本。

一些库开启了 go mod 之后，各种历史遗留原因加上循环依赖，灾难就降临了

最典型的例子就是 etcd 了，etcd, grpc, viper 循环依赖…，碰到过的人，肯定都觉得坑爹

想解决这个问题，只能一个个 replace，但是后续升级依赖，可能就又会碰到这个问题了。

只要项目复杂，包管理器再好用…也会变得复杂，只能从源头上处理这个问题，不要随意使用第三方库，非要用的情况下，要进行多方面考虑。
比如，库的活跃程度，库是否引用了第三方库，库引用的第三方库是否引用了第三方库……

[wiix]

@gaoshiba try-with-resource 语法都出来快 10 年了，你不学不用让怎么帮你，对吧……

[Mithril]

你说别的我也就信了。。npm ？？？

[sunzhenyucn]

构建工具和包管理器怎么会有可比性？写 Go 我还在用 GNU Make 来帮助软件构建，并没有感觉比 Maven 方便到哪里去。

[sampeng]

@Jirajine cargo 只是编译工具，构建工程是 build.rs 。虽然这样一来无限的可能，但是，体验远远不如 gralde 直接的 dsl 去写。兼容性的坑在任何工具都会出现，只是多少问题。从整体上看，maven/gradle 开箱即用还是很舒服的。

[jeffwcx]

@hengyunabc npm 又不是拿来打包的，webpack 打包现在都有 treeshaking，不可能一打包就是几百兆吧

[tommyzhang]

npm 这种二把刀也好意思说

[ciaoly]

老板：就喜欢看你们吵来吵去，谁也不服谁，然后乖乖地在我手下拼命干活的样子。

[misaka19000]

真是时代变了，pip 和 npm 居然也敢来和 maven/gradle 来比较了 :)

[ZnBDPang]

慎防钓鱼

[iseki]

没用过 pip 不评价，gradle 确实不能一键跑命令加依赖，但是 kt 写起来舒服坏了…
npm…也许 package.json 看起来一目了然，但是有点事还是要去自己折腾 package.json 以外的东西。暂且不提 node_modules 这破玩意儿

[lllpla]

npm 是最挫的包管理 没有之一

[gaoshiba]

@wiix 哇，哪里都有杠精，喜欢杠一下啊。

[zhaiduo]

我的理解，用法越复杂，其实是越灵活的，兼容性越好。

[beginor]

各位，我工地上缺抬杠的，谁来报个名？😂

[ikas]

说一个场景吧,一个多人多模块的项目,每个人有各自的模块,使用 maven,然后配置 profile,modules,SNAPSHOT 等等,每个人只需要加载自己的模块代码,别人的项目直接从 maven 私服下载编译好的 SNAPSHOT 版本,每个人自己的模块编写一定程度后也上传 SNAPSHOT 版本到私服.如果需要调试其他模块,那么勾选需要的 profile 即可.
不知其他工具如何实现呢

[wiix]

@gaoshiba 所以，是谁在杠？

[tikazyq]

来鱼塘赏鱼

[gaoshiba]

@wiix 你不是杠精吗？我只是提到一下学到新东西了。你就开始来说我不学不用了，我为什么要学？有的东西知道也好，不知道也罢，能影响我多少？考清华北大的书都出来了几百年，你不学不用让我怎么帮你？对吧？？杠精同志？？？

[yinzhili]

npm 这种玩具，也配和 maven 相提并论吗

[uselessVisitor]

@matrix67 带好人

[apeCoder]

虽然 maven 不怎么样，但是 npm 事真的垃圾，

[SuperXRay]

第一次听到贬 maven，gradle 而夸 npm(pip nuget 不理解不评价)
和 java 的包管理比，前端的包管理就像一坨屎

[SuperXRay]

#156
Sun<Neutron<Black hole<node_module
这恶搞的张经典图大家应该不陌生吧

[unbright]

这个对比不太恰当，包管理仅仅只是 maven 或者 gradle 的一个功能而已，项目构建测试部署等等一套他都可以做，准确的说应该是工程管理了，npm 才是包管理器，要构建还得结合其他的组件，而且下载的那个 node_modules.。。。。。。个人感觉他是最垃圾的了，没有之一