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

[SystemLight]

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

[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 把包版本锁定一个稳定版呢，-_-