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

[SystemLight]

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

[Cooky]

“只要把东西搞的复杂到能把新来的人吓走，老板就不敢炒掉我”

[charlie21]

二逼答案：因为不需要，又没人付钱
歪理答案：复杂的方案是提高了从业人员的门槛，从侧面劝退 /降低了从业人员总人数，减少了业内竞争压力，同时有助于把脑力用在更重要的事上（相对地 前端开发的 package manager 一只手都数不过来）
普通答案：业界选择 遵守就是了

[liprais]

你用 pip 解决过版本冲突么......

[Cbdy]

UP 说得很有道理，Java 可以弄一个简单点的

至于现状为啥是现在这个样子，可能是 Java 程序员普遍喜欢过度设计有关系吧

[12101111]

你可以看看 c/c++的一堆怪物，GNU make, BSD make, autotools, CMake, meson, ninja, 各个都有自己的 DSL

[lasfresas]

java is a horrible language.

[love]

Java 的特点就是很擅长把简单的事搞复杂，从软件架构风格就可以看出来
很多年前从 Java 转到 PHP 时第一感觉是写代码真直白每一行全是干货～

[yikuo]

我反而觉得 gradle 比 npm 简单多了

[TypeError]

go mod 也比 gradle 简单

Java 历史包袱太重了

[Sharuru]

npm (originally short for Node Package Manager)[4] is a package manager for the JavaScript programming language.

Gradle is a build automation tool for multi-language software development.

: )

[ZeawinL]

存在即合理，node 不也有 gulp 之类的…
配置易读，代码易写

[WispZhan]

拿一个 纯粹的包管理 和 构建工具 比真的客观？

要是真的搞懂了这 2 类工具的差别，或许会不会用已经不重要了，容不容易用已经无所谓了

[Cbdy]

@Cbdy 另外，Gradle 其实应该和 webpack 比

[fz420]

比起 java， 看到 go 的 mod, rust 的 cargo 相对来说发展的相当易用啊。
转 go/rust 吧

[yeqizhang]

有些动不动就是 java 故意把东西搞复杂的阴谋论。

我寻思着这玩意明明是国外搞起来的东西呀

[littlewing]

maven 不是包管理器

[hengyunabc]

现在黑 JAVA 成了潮流？ npm 和 go 用得不多，但也可以说下自己的理解。

1. maven2 是 2005 年发布的，但它现在来看还是非常领先的。
2. maven 设计了打包的各个生命周期，概念，并且非常容易写插件，生成源码，添加资源等等。
3. 用 maven/gralde 打包其它语言是相当容易的，反过来估计能做到的不多。

npm 根本和 maven 不是一个层面的对手。从两点设计就知道了：

1. 每个应用自己一个 node_modules 打包目录，无数的人搜怎么清理。（现在已经改为链接到~/下面了）
2. 小版本默认升级，`~`和`^`

npm 一个笑话就是：一个工程不说十个月，就是一星期后，就可能打包不成功了。

一个 java maven 工程，十几年过去之后，仍然可以正常打包。一个 maven plugin，十几年之后，仍然能工作。

以前还有笑话是：Java 打包出来的结果文件大。

实际上过了几年，发现 nodejs 打包结果动不动就几百 M，go 打包结果也是越来越大了。


go 的包设计非常的奇怪。

1. import 一个 git 仓库，如果这个仓库被攻击了呢？怎么保证安全性？过了好多年，才加了一个 hash 的补丁
2. go import 一个 git 仓库，是因为本身它编译时要求全是源码，不能生成中间结果
3. 作为一个用户，我要盯着一个依赖的仓库的 hash 值？依赖管理本身不应该看的是版本号么？

[across]

npm 才是最麻烦的吧，难道是因为我接触 web 最晚？
npm 这种开源工具，工程上就非常发散，webpack 写的头大，自动安装更多是受益于开源免费试用。

[lewis89]

真的不复杂，上家公司被搞过前后端分离，唯一的疑惑就是为什么 npm 过几天就打包编译不成功了... 难道代码会变质？我啥也没动啊.. 用 maven 后没遇到过..

[tinyuu]

maven 复制粘贴 xml 又标准又简单。

[lionseun]

版本需要精确控制，反观 npm pip 的那种升级性版本支持，对于找 bug 就是一种隱性

[echo1937]

前几楼是无知还是傲慢，动不动就是阴谋论。

[vjnjc]

感觉打包的痛点是版本冲突，其他的没看出啥区别

[murmur]

只有没干过项目的才会盲喷这东西多复杂，再复杂的东西只要能抄作业什么都可以搞定，spring 年代就有 springside 给你抄作业了，还真的手写配置啊

最怕的是什么，怕的是抄作业都能抄不过

[hantsy]

npm 包管理兼容性最差。

软件包依赖问题，除了 Linux 系统的 DEB，好像软件开发领领域 maven 算是鼻祖类吧，除了包依赖管理，Maven 一套生命周期才是神器，黑 Java 真是笑话。

[FreeEx]

关联这个帖子看就会很喜感 -.- https://v2ex.com/t/752463#reply9

[magicZ]

@love php 天下第一，不愧是多年前就逃离 java 的 phper.

[impl]

Java 以前用的是 ant，一些项目像 Tomcat 还在用 ant

[lixingjun]

历史包袱，npm 确实方便，但也有很多缺点

[redtea]

一直用 Maven，挺不错的。最近用了 Python 写个项目，它的包管理方式才叫可怕，不能任性升级，否则就无法运行，安装包的顺序也需要注意，否则影响其他包就安装不了，为了安装一个包，我甚至不得不安装 C++编译器。

[troywinter]

因为你现在站在历史的肩膀上，你用 pip 处理个依赖冲突试试？ python 这么多年了都没有个可用的依赖管理，java 面向的是企业级市场，不能说，这个依赖冲突了就改代码，客户停机一次上亿的损失，当你处理了更多 2b 的需求就会知道为啥要设计这么复杂。

[xarthur]

gradle 一点也不复杂啊……

[xarthur]

gradle 无脑往 dependences 里写依赖就行了

[pursuer]

maven gradle 主要是构建工具，而不仅仅是下载依赖，构建不是一个简单的工作，可以看下 make autoconf ninja cmake 构建工具的发展历史。不过我对 gradle 可没有太多好感，一个用于 java 开发的电脑不注意的话电脑上会存有一大堆不同版本的 gradle 。实际 pip/setuptools 也有 python 项目构建功能，可以看看 setup.py 是怎么写的

[lower]

要什么包管理？
手动复制粘贴 jar 包进 lib，一把梭就是干
打包？把一堆 class 用 rar 打包就行啦，多方便

[hafuhafu]

maven 管理依赖会复杂吗...我陷入了沉思。
npm I XXX 和复制粘贴一个<dependency>我觉得都没啥心智负担。
我发现有些人对 java 的恶意真的是无限大，费尽心思就要把 java 往“古板”、“复杂”、"不会变通"等刻板印象和标签上引。

[limuyan44]

难道你是前端出身吗，npm 也配拿出来比了么。

[blessingsi]

java 确实有一些问题，但是拿 npm,pip 黑 maven 真的合适？不说 maven 除了依赖管理之外的功能，就算是单纯比较依赖管理，这两个都被 maven 秒杀吧？要不然还要那一堆 python 虚拟环境工具干嘛用

[micean]

依赖管理不就复制粘贴的活，哪里复杂？？？

[wangxiaoaer]

前几楼简直无知的要死，我都看的怀疑人生了。

[zjqzxc]

@liprais 解决过，版本冲突也算是常见问题了；一般 requirements.txt 默认都带版本号，配合 virtualenv 食用。

[ScepterZ]

@hengyunabc go 现在不也是看版本号么

[afewok]

年轻人，不讲原理，就看谁入门少敲几个字符，就评价，这好嘛？这不好。

[superrichman]

maven 对新手很不友好，配置环境这一步就能吓退一堆萌新，各种配置的复杂程度根本不适合入门的人去用。

查看 maven 默认配置，卧槽一堆英文，卧槽 xml 文件怎么长得这么难看，马老师，这写的是甚么？

萌新好不容易配置对了，结果一个包半天下不下来，改来改去也不知道哪里出问题。依赖里的某一个文件卡半天下不来，得一层一层找到出问题的文件删了再下，有时候还要重复好几遍，太难了。

依赖 update 半天还是原来的，有时候 clean 好几遍才能
update 成功，有时候还要 force update 。艹，这么多项目都要改，太难了。

还有些奇葩的包不在 mvnrepository，又要做特殊处理，萌新表示太难了。

[xarthur]

@pursuer gradle 版本多其实也好解决，你设置一下，不要用 gradle wrapper （也就是 gradlew ）直接用本地安装的 gradle 跑就行了，gradle wrapper 不是必须的。

[abcbuzhiming]

其它的我不评论，npm 这个玩意有啥资格来评价 maven

[goalidea]

java：哇擦，无情，不讲武德！ node 年轻人耗子尾汁！

[Lemeng]

不算复杂

[saberlong]

@hengyunabc 关于你说的仓库被攻击引入 hash 的问题。java 也存在，任何从仓库下载的都存在篡改问题。而且 go 也能做到从企业内部的仓库下载。

[xcstream]

不许百度 linux 服务器上
空手写个 web 服务
node 只要 5 分钟

[chihiro2014]

我一直觉得前端的代码，过了几周就打包不了，maven 还没遇上这种问题

[BBCCBB]

maven 可以用命令行的

[EminemW]

不要胡说霸道，依赖文件写好并不需要改配置文件

[EminemW]

还有 maven gradle 应该叫项目构建工具，并不是包管理工具

[ikas]

等到他们都实现了 maven/gradle 的功能,回头再来看看,不就又是第二个第三个"maven"么

[hantsy]

@xarthur 如果说到 Java 内部嘛，Gradle 版本兼容性简直是灾难。各大版本之间配置升级旧的配置格式会被废弃删除，大版本几乎不兼容，想用 Gradle 6.7 去运行 5 时候创建的真实项目，基本上不修改配置不可能运行。Wrapper 就是为了锁定版本，解决了这个问题，但同时也要额外下载相应的 Dist，我的用户目录光 wrapper 下载的 Gradle Dist 都是超过 20G 了。项目如果使用 Gradle，你几乎要时刻更新到最新的 Gradle 格式，以保证你的代码在别人拿到后，可以使用最近半年的 Gradle 成功的 Build 。

但是 Maven 配置的兼容性堪称优秀。Maven 3 运行 10 几年前 Maven 2 程序一样没问题。虽然将要发布的 Maven 4 （ 3.7 版本计划被废弃了）也可能会加入 Wrapper （但个人觉得完全没必要）。

ANT 在 Maven 大规模使用之前一直是 Java 项目实现自动构建的首选。 虽然 Ant 在新项目中几乎没有多少人会采用，但大量的遗留项目一直还在使用 ANT 。ANT 并不是没进化，ANT 下的子项目 IVY 也是用于依赖管理，与 ANT 结合，一样可以利用 Maven 库，自动解决依赖问题。

SBT 和 Gradle 相似，后台一直跑进程，提供一个交互的编译的环境，只是曲高和寡，几乎只有在 Scala 项目用到（个人我也不喜欢）。

（扯远一点，Ivy 虽然可以读取分析 Maven 坐标，但它自己有一套关于依赖的设计理念，早期 Gradle 也是使用 IVY 解析依赖，后来才切换到使用 Maven 兼容方式的，目前似乎 SBT 还在用默认用 IVY 来解析依赖。）

[janus77]

java 哪来的包管理工具，都是 build 一整套
单纯说 java 的依赖包系统才是最简单的，直接一个 jar 包丢过去，不用编译生成，不用特别写什么，直接就能用。

[aureole999]

@hengyunabc 正好看的前几天的新闻，这人搞到公司内部用的包名，然后在公共仓库上传了一个同名的，就在 Apple 和微软的内部服务器上成功执行了代码。至少这点上 Go 还没那么容易，不是一个同名的包就行。而且这人说最容易搞到的内部包名就是从一些网站的 js 文件里找到，所以他攻击成功的有 75%是 npm 。

https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

[royzxq]

不是，说前端项目过几周就打包不了的是不是项目里都不用 yarn.lock / package-lock.json ？

[SystemLight]

@liprais pipenv 独立配置环境不行么

[ming7435]

npm 也配合 maven 比?你是不是还没入行?

[SystemLight]

@Cbdy 说实话 groovy 的语法我还是蛮喜欢的，挺新颖，但是可惜是领域专用语言做别的方面似乎都不太靠谱，java 的包管理是我见过做复杂的，话说.net 设计模式同样复杂的一匹，但是包管理（ nuget 和 dotnet ）却做得相当好，语法糖也相当的香

[SystemLight]

@ZeawinL 但是 gulp 是打包构建工具，难道说 gradle=npm+gulp 么，如果是这样还可以理解，可是 gulp 是解决 JS 模块化的，但是 JAVA 不是本身就支持模块化么，为什么还需要这样呢，而不是一个依赖包管理的工作呢

[SystemLight]

@WispZhan 没有搞懂 JAVA 为什目需要构建工具，而不是一个单纯的包管理，前端需要 webpack 这样的打包构建工具可以理解，解决模块化问题，但是 JAVA 为什么还需要构建呢，解决了什么问题，我记得很久之前写 JSP 的时候没有 gradle 也是用的相当好的啊

[xuanbg]

npm 那个叫简单？？？我觉得 maven 倒是挺简单的

[SystemLight]

@Cbdy 一个天生支持模块化的语言为什么需要构建，这个是我没有相同的，如果说要结合 kotlin 我还能理解，但是 JAVA 居然不把构建和依赖包管理分离开，我是想不通的，而且依赖包需要手动粘配置文件，这个是什么年代了，哈哈！！！

[xarthur]

@SystemLight jvm 是个平台，首先就有很多语言，举例来说 Scala 和 Java 或者 Kotlin 和 Java 的混编。其次 Java 语言特性的孱弱，导致了很多工具都依赖 Java 的注解来在编译期实现功能，比如 Lombok，接着还有要不要混淆，然后你可以生成字节码也可以直接生成二进制目标平台代码。最后你选择是要打包还是不打包直接一堆 class 文件呢？打包你是要 jar 还是 war 呢！

[xarthur]

*!->?

[SystemLight]

@across webpack 复杂度从宏观上确实和 gradle 有的一拼，但是 npm 工程上非常发散能否详细说说，对比 gradle 是如何解决这个弊端的么，我目前是没感受到，请详细说下，npm 包管理器不只是依赖包安装的工具么。

[xarthur]

@SystemLight 这个不是什么黑点，首先 java 光常用的公共仓库就有两个，私有仓库就更多了。其次 Java 的库不像 javascript 的库，一般一个库提供的功能非常的全，也不用三天两头加仓库。

[SystemLight]

@lewis89 老哥你这个回复我感觉我学了假前端，哈哈，npm 只做包管理，顶多是软件源安装不了，打包编译应该是 webpack 或者 gulp 这种工具做的，npm 表示这个锅不背

[SystemLight]

@murmur 并不是喷这个东西有多复杂，只是想知道复杂的原因是什么，对比其它语言的包管理好处是什么

[SystemLight]

@hantsy npm 包管理兼容性最差 ，能否举个具体的简单例子呢

[xarthur]

@hantsy Maven 相比之下 gradle 来说不够灵活，而且打包速度似乎也没有 gradle 快（ gradle 官方有测试）。gradle 还支持渐进式编译可以缓存结果。顺便 gradle 现在目标是想当个通用的构建工具，不光是用在 jvm 上。
兼容性的问题其实从 gradle4 起，特别是 gradle5 、6 已经好很多了。这点确实做的不如 maven
SBT 是真的不好用，又慢稳定性也差。

[tt0411]

在 Java 领域的很多"问题", 只有在工作一定年限并且有一定思考后才能意识到是自己的问题

[xarthur]

@SystemLight 有哪个构建工具是非常简单的吗？ webpack 也不简单啊……make 之流就更复杂了。

[SystemLight]

@FreeEx 缺失 node_modules 占空间是硬伤，但是 gradle 难道是编译时候才去下载的依赖包，然后编译完又清除的么

[SystemLight]

@lixingjun 我目前感觉的就是 node_modules 太占空间了，删除是硬伤，哈哈

[xarthur]

@SystemLight 如果你只是想构建一个 default 的项目结构的项目，我之前也说了，直接往自动生成的 build.gradle 里 dependencies 里加依赖就行了。

[SystemLight]

@redtea 包能不能任性升级难道不是这个开源依赖原本是否兼容造成的么，和包管理器有啥关系，为什么不用 requirements.txt 把包版本锁定一个稳定版呢，-_-

[icyalala]

npm 和 pip ？你是认真的吗？

[xarthur]

@SystemLight gradle 会重用不同项目里的相同依赖。

[xarthur]

@hantsy 我个人喜欢 gradle 还有一点就是它用 groovy/kotlin 做 dsl，这个比起看一堆 xml 好受多了。而且可以很便捷的写一些脚本方便自己使用，打包成可以分享的插件也方便。

[SystemLight]

@hafuhafu 可能心情上不太一样吧，毕竟 JSON 文件通俗易懂，groovy 语言看着懵逼吧，但是 java 语法糖总觉得太少了对比.net5，可能要追求稳定吧。

[xuweifeng1987]

看了下评论，笑死啦哈哈

其实 maven 和 npm 原理类似，只不过 maven 肩负的更多，maven 管理 jar 包只是很小一部分功能，看看 maven 第三方构建插件生态，你会发现更大的世界 ;)

[SystemLight]

@superrichman 哈哈，太真实了

[cleveryun]

jar 的服务器部署真香，比 npm 的方便多了。

[geekaven]

你这就好比拿文本编辑器比 idea，问为啥 idea 搞那么复杂。

[huskar]

1.python 语言对应的工具应该是 poetry 或者 pipenv，pip 和这几个不是做同一件事的。
2.java 的 maven 比其他语言的构建工具出现早太多了，可以说其他几个工具都是站在 maven 肩膀上的，所以它们可以取长补短，因此对新人来说觉得这些工具好用很正常。maven 因为出现的早，必然有其历史局限性，比如 maven 使用繁琐的 xml，而后继者普遍采用更简洁的 json，toml 或者 dsl 。
3.这几个语言和构建工具都在用，熟悉了以后觉得其实都差不多，没有什么根本性的差异。楼上有些人硬吹 maven 最好我不敢苟同，我觉得对新手而言，明显是后来出现的构建工具更简单好上手。

[sampeng]

无知当无谓，用得少就不要评论任何流行工具。

你拿 npm 给我自动生成一套项目模版试试？
你就什么都不动，无脑 npm install 试试？我现在是运维，天天被前端说怎么打包不过去 /线上功能怎么和他测的不一样，就过了一个晚上升级了小版本找谁说理去？

不要抬杠说可以去改配置。拿 npm 所有吐槽点变成正常点后，和 maven/gradle 有啥区别？ webpack 配置通俗易懂？来来来，你花一个小时看能不能教一个刚毕业的搞明白 webpack 。maven/gradle 完全没问题，都是结构化的。新人其实很好看明白例子。

前面有说 rust 的，go 的，真的很牛逼么？ go mod 发展了几年？最后是怎么诞生的，麻烦你们自己查查资料。真的好用？做自动化构建的时候真的和 java 比一个天上一个地下。rust 现在最蛋疼的就是依赖构建和自动化打包，一下下一堆包不说，项目稍微大点就是半个小时起。别扯本地。都 2021 年了，谁发版从开发电脑上打包？稍微有点团队配合，模块一没分好打包时间就上天了。下载就更不用说了，没科学上网就别想顺利开发。
这还是正常情况，最蛋疼的就是 tokio 版本，经常一不小心整个项目就编译不过去，因为有些老项目不更新 tokio，有些又用的一个版本。然后你自己得有用的最新的，一编译，哦豁，runtime 不匹配我就要去解决版本冲突…maven 解决版本冲突不要太简单

go 写的少，没怎么碰到过坑。

maven 和 gralde 的问题绝壁不是工具本身。xml 配置屎山是人配出来的。


当然，我喜欢 rust，我也讨厌 java，太啰嗦。但不妨碍优秀的东西本身的优秀。很多在 rust 里面得东西我还很希望有类似 java 的 xx 工具，不是使用惯性，我 java 也写的很少。就看点开源项目而已。

[sampeng]

@SystemLight 另外我给你解释一下为什么 java 需要构建工具，因为 java 在稍微有点规模得公司和写 js 的人的比例都最少是 10:1，你不会以为 java 后端都跟 js 一样都塞一个项目里一个 src 目录完事吧？所以你拿一个只需要几个人开发就完事的和团队作战才行的比，合适么？

[HibernatePlus]

一不用上大学就能学会的前端能和需要了解计算机原理的 java 相提并论？搞笑呢吧在这

[fox0001]

我只能说，楼主还是年少气盛。当年我刚毕业，Java 已经出 1.6 了，公司项目还在跑 1.4，甚至更老。因为升级的问题，老板还特意开了个会，提出个观点：能赚钱的代码就是好代码。曾经我觉得作呕的观点，现在算是认同了。

1 ）企业需要盈利。盲目跟风升级会带来很多额外的工作（写新代码、测试、培训人员、维护历史版本等），直接浪费很多钱。

2 ）项目需要稳定。新功能会带来新 bug 、新漏洞，测试人员不可能 100%覆盖。特别对于结算功能，算错的钱，谁去承担？

3 ）更需要关注的是业务功能，满足客户需求。

4 ）新人都喜欢炫耀技术（特别是喜欢技术对比，我当年也是这种心态），老人总想着赚钱养家。特别老板要考虑整个公司的发展。

后面公司架构师还是技术升级了，毕竟 Java 1.6 带来实在的好处。但是旧项目就很蛋疼，例如看着好用的新模块，不能直接搬过去。

[ebony0319]

楼主说的几种包管理我都用过，正常使用 java 稍微复杂一点，但是项目一大，引入的包一多，冲突就多了。很多时候需要选择 a 还是 b，很多时候也要同时保留 a，b 并且保证他们不冲突，有时候需要插件来辅助…java 在这方面真的还是非常先进。

[hantsy]

@SystemLight 来例子，https://github.com/hantsy/angularjs-springmvc-sample-boot 这个例子大概只有 4，5 年时间，你可以前后编译对比一下 NPM，Maven 的包管理。

另外，https://github.com/hantsy/signup-app 这个差不多快十年了，Maven 一样可以编译。

去年给一个前端项目 Angular 加一个 CI，全部依赖都是 Broken, 开发人员半年一直自己机器上开发，没更新依赖，然后笨号用^的话，更新后完全不兼容，Node 项目相互依赖的版本更敏感。Angular 现在自己有自动升级工具（可以更新相应的依赖），不然的话，自己手动升级，你还得仔细读它的依赖库（ rxjs, karma 等）版本多少。

[TheWidowMaker]

好家伙，真的还有人拿 npm 来给 java 的包管理说事的，这是我万万没想到的

[hantsy]

@xarthur 觉得 Groovy DSL，Kotlin DSL 来写配置就是灵活？？？

这些 Maven 早就支持了。https://github.com/takari/polyglot-maven

Atom polyglot-atom
Groovy polyglot-groovy
Clojure polyglot-clojure
Kotlin polyglot-kotlin
Ruby polyglot-ruby
Scala polyglot-scala
YAML polyglot-yaml
Java polyglot-java
XML polyglot-xml

虽然 Gradle 发展这么多年。但是很插件还只是有 Maven 版本，没有 Gradle 支持。生态方面 Gradle 还是不行。

[hantsy]

习惯方面不用说了，每个人看法不一样。

就之前说那个兼容性我都是受不了 Gradle，但日常我也用，有些项目用什么技术不属于我控制的范围，不然我个人也不产生 20G Gradle Dist 垃圾文件。（我整个下载的 Maven 依赖库也才 20G 左右）

我个人新项目肯定不用 Gradle 的。

[hantsy]

NPM 比较蠢的是有全局缓存，每个项目中在 node_modules 又再 Copy 一次，硬盘杀手啊。

[justin2018]

npm 就是一个坑货

使用 npx npkill 释放硬盘空间~

一个月清理一次 可以释放最少 10G 空间

年前把家里的工作机清理了 释放了 100G 的空间 o(╥﹏╥)o