是否有必要抛弃 Maven 之类的项目构建工具？

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

This topic created in 3487 days ago, the information mentioned may be changed or developed.

事情是这样的，在公司内部，两个项目小组都用 Maven ，我在其中，但是另一个小组（不在前面两个小组之内）的同事反对使用 Maven ，他建议使用原始的方式，将第三方 jar 包直接放到工程代码里，代码和 jar 包一起放到 git 里做版本管理。

这样有必要吗？

注意，并不是问是否有必要抛弃 Maven 而转向其他工具例如 gradle 等，而是问是否有必要抛弃这一类项目构建工具。

个人认为， Maven 并没有降低生产力，只是稍微有点学习成本，这点学习成本其实也非常低，此外它能很方便地管理第三方包依赖，简化代码库，显著提高生产效率。

希望大家说说自己的看法。

Maven

jar

代码

抛弃

72 replies • 2016-11-04 16:35:35 +08:00

monsoon

Nov 2, 2016

转 Gradle 。而且 Gradle 导入本地的 jar 比 Maven 方便 500 倍。
放 jar 来版本管理是 15 年前的做法……

ixiaohei

Nov 2, 2016

gradle 底层还是 maven 那堆东西，坐标，插件。用 gradle 更增加团队学习成本，你要是用回 ant 那种最原始，好多新手估计搭建一个项目去找 jar 包，估计就得花很久，还不一定能搭起来那就 233 了，另外 maven 这种工具长处在构建，等你们用上持续构建你就知道还是得用 maven 。

lightening

Nov 2, 2016

他是从 15 年前穿越过来的吧？

fovecifer

Nov 2, 2016

在我看来 jar 包是二进制文件（实际上应该不全是），用 git 等源码管理工具来管理二进制数据本来就是作死

PS ：最反感的就是你说的这种同事， maven 起码算是目前的最佳实践之一，他就没想过为什么吗？觉得就自己牛
其他无数的开发者都是傻 X ？连这么点新鲜事物都不能接受这是作为开发者最基本素质的缺失

zpf124

Nov 2, 2016

嗯很强...
我们项目 jar 不算多也不算少，大概有 500M 左右的了，算上图片啥的差不多快 1G 。
往 git 仓库里塞将近 1G 数据，嗯很强... 新检出一个项目爽到爆。
另外手动解决依赖也爽到爆。

plqws

Nov 2, 2016

说白了要么蠢不会 maven 或者要么懒懒得用，真不知道直接放 jar 有什么好处

murmur

Nov 2, 2016

刚开始看还以为要用 gradle
后来看直接拷贝 jar 包就呵呵了

funky

Nov 2, 2016

maven 长处在构建。放弃 maven 工作效率会降低不少

eimsteim

Nov 2, 2016

如果直接导 jar 真的那么好，为什么 Maven 和 Gradle 会出现？另外， git 是做代码的版本管理的，不是用来存 jar 包的。

PEP4JASON

Nov 2, 2016

问题不是说用什么方法构建项目而是沟通

billlee

Nov 2, 2016

不是蠢就是懒

kingcos

Nov 2, 2016 via iPhone

直接拷贝太麻烦了，还经常容易出错，或者版本问题
Maven Gradle 都可以直接解决，就是看网络了

uxstone

Nov 2, 2016

提用 jar 的那位是组长吗?
不是的话,就当他放了个屁...

echo1937

Nov 2, 2016

这个开发是谁招进来的？

zhuangzhuang1988

Nov 2, 2016

不能放弃

SoloCompany

Nov 3, 2016 via iPhone

1. 沟通
2. 至少要搭个 nexus mirror 解决 gfw 的问题，或者直接用国内现成的 mirror

yidinghe

Nov 3, 2016 via Android

在你同事看来，项目的依赖包一旦确定就不会改了，但实际上不是这样，特别是公司自己开发的包，经常会有更新。如果几个项目都用的话，统一发布一起更新是最便捷的。

aias

Nov 3, 2016 via Android

不管怎样，先说一声 Gradle 大法好！

bombless

Nov 3, 2016 via Android

不知道你们那什么情况，不过包管理器还是很顺手的。

感觉如果不是写业务代码而是写一些基础设施，还是可以抛弃包管理器的，哈哈

ljcarsenal

Nov 3, 2016 via Android

这么多 java 开发者啊

vietor

Nov 3, 2016 via Android

SBT 还是比较简单的

profoundexplorer

Nov 3, 2016

@vietor 死变态？舒伯特？苏炳添？
开个玩笑。
能查到 SBT 是什么

Troevil

Nov 3, 2016

当然 maven 大法好了 .
android 用 Gradle
其他 maven

hpeng

Nov 3, 2016 via iPhone

你们居然选择放弃先进生产力，回到刀耕火种的时代，佩服

bigdogbigpig

PRO

Nov 3, 2016

哈哈哈哈，快点同意他的意见让他们组把 jar 包全部上传上 git 啊，这样生产力得到了极大的保障！！！

zacard

Nov 3, 2016

jar 依赖问题搞死他。。。

faywong8888

Nov 3, 2016 via Android

这个公司的技术 leader 应该好好学习下！

VeryEase

Nov 3, 2016

用 maven 有什么不好，哪个顺手用哪个，你们居然没有能拍板的人把这些事情定下来。

tabris17

Nov 3, 2016

这人是个智障

cedoo

Nov 3, 2016

安卓用 gradle ，其它用 maven ，恩，没错！

brucefeng

Nov 3, 2016

可以自己公司内部建一个 maven repository ，这样也可以把公司自己开发的 jar 放在里面，就没必要在项目内部保留 jar 包了

twogoods

Nov 3, 2016 via Android

你要面试的时候这么说估计...

tony1016

Nov 3, 2016

你只需要简单的告诉他，请帮我在 spring 的官网上，下载一个 spring 的 jar 包，他就傻眼了

wupher

Nov 3, 2016

1. 很多小公司仍然采用传统 Jar 管理模式。好处是项目 clone 之后，马上即可编译运行。缺点是要人工解决 Library 包依赖问题，明明 Maven ， Gradle 都可以自动解决的。如果需要自动编译支持，一般采用 Ant 脚本方式。十分古老的版本管理方式。不过，小公司的项目经常是不断重复，经常是将旧项目拷贝，再翻一版， Lib 包永不升级，这么干于它而言更方便。

2. 使用 Maven 、 Gradle ，甚至在公司自建私有 Repository 。相对现代且自动化得多。大多数 Github 上的 Java 项目使用此种方式来管理包依赖。优点：主流，自动化解决依赖，对于 CI 等开发工具支持最好。缺点：自从 Maven 的 OSC 镜像关闭以来，你最好能有个代理。

swim2sun

Nov 3, 2016

难以置信... 这是在开倒车

ccjeaty

Nov 3, 2016 via iPhone

问问他为什么啊，贴出来大家学习学习

lytofb

Nov 3, 2016

要么远离这种同事，要么成为他们的上司

cjyang1128

Nov 3, 2016

可能你那个同事比较恶心 Maven 的依赖传递吧

enenaaa

Nov 3, 2016 via iPad

其实我也比较讨厌签完代码后还要等半天下依赖库的

v2orz

Nov 3, 2016

等他什么时候导出 baidu/google 到 jar 下载到工程中，结果弄到一个被恶意改动的文件，最后搞出大新闻，他就会吸取教训了
而且手动复制 jar ，用不了几个月没人能说明白 lib 下面一堆文件分别是干嘛的了，亲身体验

lawrencexu

Nov 3, 2016

之前我司一个老项目就是用 Ant 这么搞的，我花了三个月时间把上万行的 Ant 脚本转成了 Maven 编译，之后才有了一系列的技术改进和升级，单用 Ant 根本没法搞，也许加上 Ivy 可以。

tomczhen

Nov 3, 2016

小孩子才分对错，成年人只看利弊。

我反正是很反感一些人上来就先贴个标签，带个帽子然后把别人批判一番——这跟以前的红卫兵小毛孩有什么区别？

技术选型、推进说白还是博弈，每个人的利益点不同。当然，有些人就根本不是理性经济人，这种人你就不要和他一般见识就好了。

如果当前项目管理方式没有问题，或者问题还不大——大不了加加班，也能解决。作为管理层，如果新技术不能带来“利益”自然是没什么动力推进的，再说了，很多混到管理的“大龄前码农”，下班了还得去抱老婆带孩子。学习成本再低那也是成本，而且风险再低那也是风险不是？

作为下面的码农，这些依赖管理工具， CI 理念又不能直接加工资，毕竟大多数公司招人最重要的还是靓丽的履历表，那些高大上的技术关键字才符合 HR 的基本价值观。

道不同不相为谋。楼主稍微推一下就行了，公司项目代码管理什么的就别掺和了。该继续加强自己就继续，没什么加强的就准备换换环境——就算没法改变世界，改变一下自己还是可以的。

youxiachai

Nov 3, 2016

你的同事..还活在 20 年前的世界...

firefox12

Nov 3, 2016

如果没有内部的仓库懂的人不多，的确直接 jar 包更好。这是基础建设，长期的收益大很多！

ooTwToo

Nov 3, 2016 via iPhone

OMG …

Ouyangan

Nov 3, 2016

建议辞职~~

Miy4mori

Nov 3, 2016

不知而不知其不知者，愚者也——避之！

twiceyuan

Nov 3, 2016

@enenaaa 所以你喜欢签半天代码吗？ ¯\_(ツ)_/¯

reeco

Nov 3, 2016

远离这类同事，没有必要解释

Chrisplus

Nov 3, 2016

Gradle 底下也是 maven 那一套。

"Maven 并没有降低生产力"， maven 是在提高生产力好么？当然也要看项目的具体情况。假如引用的外部 jar 包长期不需要更新且稳定，也不妨放个 jar 包进去。但是有长期不需要更新且稳定的东西么，还是说你们这个项目一个月做完，然后交付收工，今后再无瓜葛？

楼上说的对，远离这类同事。

lululau

Nov 3, 2016 via iPhone

这就是不会用吧，啥也不想学，拷贝 jar 估计 cp 命令也不会用，只会 Windows 资源管理器里 Ctrl-c 的那种

lululau

Nov 3, 2016 via iPhone

竟然会用 git ，真不信！

0915240

Nov 3, 2016

我以为是要转 gradle 或者 sbt 。。。

aaronmix

Nov 3, 2016

maven 跟 gradle 在 dependency 管理上都差不多，但是 gradle 比 maven 强在 build script 是可编程的，而 maven 是 xml ，灵活性不够。以前经常是 maven xml+各种插件+自己写的一些脚本，用 gradle 直接可以把脚本写在 build script 了，方便很多。
至于 jar 是不是在 local ，其实 google/fb 的 build system(buck/blaze)都是保存在 local 的，主要是为了 performance 考虑。

forbreak

Nov 3, 2016

我们公司之前的也是不用 maven ，后面教他们用了之后，刚开始都是各种抵触。然后后对公司项目进行整体升级改进的时候，都体会到了好处。

intsilence

Nov 3, 2016

建议开倒车的同事一定非蠢即坏。

billwang

Nov 3, 2016

我其实想问一下大家都用 maven 的什么 mirror ？现在的好慢

ibeyond

Nov 3, 2016

在大家看来，写 MakeFile 的可能都是顽固不化的老怪物了。。。

uxstone

Nov 3, 2016

@billwang
用 uk 和阿里云

如果实在太慢就 -DsocksProxyHost=127.0.0.1 -DsocksProxyPort=1080 走代理，

tracymcladdy

Nov 3, 2016 via Android

远离这种同事+1

1120101929

Nov 3, 2016

@billwang 阿里云

1120101929

Nov 3, 2016

单说一点，人工管理 jar 包，想看源码怎么办

evlos

Nov 3, 2016 via iPhone

智障同事

JohnSmith

Nov 3, 2016

方向盘都扔了，一脚油门到底，直道没啥问题，遇到弯道 GG

Ouyangan

Nov 3, 2016

@billwang
```
<repository>
<id>mvnrepository</id>
<name>mvnrepository</name>
<url>http://maven.aliyun.com/nexus/content/groups/public/</url>
<layout>default</layout>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
```

Ouyangan

Nov 3, 2016

@1120101929 手动下载源码包,再关联