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

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

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

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

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

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

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

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

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

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

OMG …

建议辞职~~

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

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

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

Gradle 底下也是 maven 那一套。

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

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

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

竟然会用 git ，真不信！

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

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

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

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

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

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

@billwang
用 uk 和阿里云

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

远离这种同事+1