![]() |
1
37
对于一个开源项目,Maven有一些优势,特别是对于你的贡献者(例如mvn eclipse:eclipse)。 如果你选择Maven,你必须严格遵守的一条规则是:不要与工具对抗。按照Maven的建议准确布局项目,遵循其所有约定和最佳实践。你与Maven的每一次小争执都是你不用为项目编写代码的一天。 还要预先考虑您想在哪里部署工件(您要托管自己的存储库吗?)。 不要害怕使用Maven以外的东西(例如Ant)。你的项目的成功将取决于项目本身,而不是它的构建工具(只要你选择一个最好的构建工具,Ant和Maven都是)。 |
![]() |
2
29
就我个人而言,我不是粉丝。我同意查尔斯·米勒的大部分观点 says about it being broken by design 它确实解决了一些问题,但它也 introduces others . Ant 它远非完美,但它更强大,记录也更好。确实需要 some discipline to use it in a modular way 不过(这是Maven试图解决的问题之一)。我认为发明比Ant和Maven更好的东西并不难,但这个工具似乎还不存在。 如果你喜欢Maven的依赖管理,但不喜欢Maven,你可以在Ant中使用 Ivy 。我对这种依赖管理风格的问题是 fragile 由于你无法控制的因素。一个有意义的用例是,如果你的组织内部有很多相互依赖的项目。在这种情况下,一切都在你的控制之下,它可能会很好地工作。 编辑 :我忘了补充一点,即使你不喜欢Maven,也不能忽视它。如果你编写其他人使用的开源库,他们会希望它们在Maven存储库中可用,这样他们就可以从Maven构建中轻松使用它们。 EDIT2 :既然你已经澄清了你的主要兴趣是为其他Maven用户提供开源库,那么值得注意的是,你不一定非得使用Maven来实现这一点。这是 a set of Ant Tasks for publishing to a Maven repository 因此,如果你想继续使用Ant来构建你的项目,你可以这样做,但仍然可以使用用户来满足你的Maven。 |
![]() |
3
12
如果你的项目很“简单”,那么maven可以让你快速启动并运行。简单地说,我的意思是你有一堆代码、一些资源、一些测试类,所有这些都与一些第三方jar一起组成一个应用程序。 当你想做一些不寻常的事情,在某种程度上特定于你自己的项目时,你最终会把所有的时间都花在让maven做你想做的事情上,而没有时间处理你的代码。对我来说,这违背了使用智能构建系统的目的。 Maven在不工作时帮助您诊断问题也很糟糕。构建脚本是由不直观、不自然的xml组成的不可读的片段,这当然可能是您喜欢和正在寻找的(如果您有蚂蚁视觉)。 我爱maven。Maven充满了善良和希望。我也讨厌maven。 编辑: 哦,eclipse的maven插件太棒了。 |
![]() |
4
10
当Maven从1.x过渡到2.x时,我很不幸地使用了Maven。它几乎消耗了我们一位高级团队成员100%的时间。我们最终取消了它。 然而,最近我有机会重新访问maven,我想说它已经有所改善。我的一个主要问题是缺乏好的文档,但在阅读后 "Maven: the definitive guide" ,我会说这更容易理解。 随着 m2eclipse eclipse插件,管理依赖关系变得轻而易举,它有一个很好的依赖关系可视化工具。 总的来说,我认为Maven在项目开始时是一个很好的工具,但一旦你的构建开始变得复杂,它可能会开始迷失方向。 |
![]() |
5
8
maven有一些非常好的地方:
此外,maven还可以做一些蚂蚁的事情。 对我来说,缺点是很难将项目移植到它上面。最好从头开始。此外,maven广泛使用插件来完成其工作,但在这方面并非一切都是完美的,而且还没有适用于所有事情的插件。 |
![]() |
6
5
使用任何构建工具的主要原因之一是获得可重复的构建。也就是说,你今天所做的构建可以在几年内完全复制。根据我的经验,Maven在创建可复制构建的测试中失败了。 这些问题源于它是一只庞大而复杂的野兽,有许多运动部件。每个部分都有自己的发布周期,版本经常相互冲突,破坏您的构建。调试这样的东西非常复杂。 我使用Maven进行开源工作,因为它相对较快地生成了一个合理的网站。这是非开源开发人员很少感兴趣的事情。即使有了这项任务,我也经常花很长时间试图弄清楚为什么事情没有按预期进行。对于开源工作,我通常使用ant来实际生成构建(jar),因为它是可靠的。 最后一点。如果你正在编写一个开源项目,你可以 有 以某种方式使用Maven。如果你的项目很受欢迎,那么你需要把它放在中央Maven存储库中,如果你不使用Maven,这会变得更加棘手。 |
![]() |
7
4
我个人真的很喜欢Maven,还有很多其他人也喜欢。Maven2的声誉比Maven1好得多,OSS社区似乎有一种趋势。对于有很多不同项目的商店来说,它确实有助于保持一致性,你不会觉得你在每个项目上都用Ant脚本重新发明轮子。 为了解决您的问题,如果您至少将jar提交到中央存储库,那就太好了。您不必用maven替换现有的构建过程,但您至少必须维护一个包含项目依赖项的POM。 http://maven.apache.org/guides/mini/guide-central-repository-upload.html 这将使用户(使用Maven或Ivy)更容易下载和安装jar,从而使您的项目受益。 如果你决定使用maven进行构建,它可能会增加你对项目的参与,因为它会在一定程度上降低进入门槛。一旦您使用maven构建了项目,想要从源代码构建的人只需运行“mvn install”即可。(FWIW,在某种程度上,使用Ant/Ivy也可以实现这一点)。 |
![]() |
8
3
我们有一个开源开发人员社区,他们独立地从事自己的项目。其中几个项目使用了其他项目中的库。如果没有依赖管理,我们会在jar中遇到循环依赖。蚂蚁并没有帮助解决这些问题(这是在常春藤之前,我还没有使用过)。通过使用maven和部署jar,我们设法减少了依赖关系,并减少了问题。因此,我们从依赖管理工具中受益匪浅,我个人发现使用maven的努力非常值得。 |
![]() |
9
3
JavaPosse在 recent podcast #217 人们的共识是,它在如何允许您构建项目方面非常严格,但它的使用正在增长,并且它可能会提供一个跨IDE标准来表示项目。 更新 Javaposse还在去年春天的Java综述09上主持了一场内容丰富的会议,题为:, "Maven with Pain?" 我笑了(带着惊恐的同情),在录音快结束时,一位参与者讲述了插件更新如何在生产发布前两天破坏了他们的构建。 老实说,我避开了它,很大程度上是因为我觉得这个名字很烦人。然而,管理第三方库依赖关系的能力很有吸引力。 更新 对于那些对我的非理性观点持有非理性蔑视的人,让我向你展示一下“maven”在我脑海中浮现的景象:
是的,在我看来,埃德娜·莫德是 这个 “maven”的缩影。我不想她在我的楼里太专横! 什么名字更好?发明的单词最适合谷歌搜索结果。为了给人留下好印象,把它们植根于具有积极内涵的真实词汇中。 |
![]() |
10
2
使用Maven的一个主要好处是它
将“项目对象模型”外部化
(因此
所有主流IDE都在maven支持方面投入了大量资金。打开项目时 在您选择的IDE中 ,它将采用Maven结构,您就可以开始了: 你通常把所有 IDE元数据 (.iml、.project、.classpath等) VCS忽略列表 . 显然,持续集成引擎以类似的方式从基于POM的方法中受益。 有一个学习曲线,也有一些限制,但你会得到很多回报。 |
![]() |
11
1
Maven可用于管理项目的整个生命周期,从开始到部署。如果你需要这些,那么Maven就是合适的工具。如果你只是在寻找一个依赖关系管理工具,你可能想看看 Ant's Ivy 我也是。 它已被用于我参与的大多数项目中。虽然有时会令人恼火(配置和文档),但它为我节省了很多时间。Apache的大多数基于Java的项目都使用Maven。 Maven是否有效,实际上取决于你想让它为你做什么。 yc公司 |
![]() |
12
1
我们正在为一个非常大的项目(超过15个模块)使用maven,我们努力不去对抗这个工具,但 1) maven解决了90%的常见问题,但如果你正在努力解决另外10%的问题,那么它总是一团糟 2) 生命周期管理一团糟。即使你为你的事情选择了一个正确的阶段,有时它也不起作用。而且你不知道为什么 3) 我们奋力拼搏,但最终还是放弃了:我们使用maven的ant。有时我们甚至用ant来调用maven。现在,甚至不要试图认为我们很糟糕:如果你能看到我们构建过程中某些步骤的复杂性就好了。..只是maven在构建复杂项目时经常妨碍你。 4) 本地存储库管理是一种负担。文物不好。以及其他类似产品。 总而言之:我建议使用Ant(如果你想进行依赖关系管理,也许可以使用Ivy,但我从未尝试过) 再见 斯特凡诺 |
![]() |
13
1
马特·雷布尔有一篇博客 http://raibledesigns.com/rd/entry/comprehensive_project_intelligence_with_jason . 我听说大多数使用maven的人都不喜欢它。 |
![]() |
14
1
一些朋友告诉我,Maven有点像NetBeans:两者都有某种污名,这种污名曾经是应得的,但现在不再完全有效。由于缺乏文档和XML/Jelly,我讨厌Maven1.x。 后一个问题可能会得到解决,因为Maven2更加面向Java。糟糕的文件记录的耻辱仍然存在,但我不知道这是否公平。 ( 如果 这仍然是公平的,那么Maven团队真的丢了球。) POM和依赖管理都是很酷的想法,但人们想知道它们是否会被一个新的工具所吸收,就像C++引领新语言一样。 最后一点:Ant和Maven之间的二分法有点错误。Gradle和Gant是Groovy领域的构建工具,它们提供了很多功能,即使是对于直接的Java项目也是如此。因为他们使用Groovy,所以简单的任务真的很简单(与Ant中痛苦的XML构造相反);然而,它们与Ant有很强的集成,因此有一系列丰富的“困难”任务。 |
![]() |
15
1
在我们公司,我们已经慢慢开始转向Maven,试图在不同的组件构建之间实现一致性。现在,这是一个巨大的蚂蚁脚本混搭,试图做同样的事情。它工作得很好,与我们的构建服务器(Hudson)很好地集成,我们需要做的一些Maven不支持(或完全支持)的事情,我们基本上抛出了一个简化的ant构建xml,并将其附加到构建过程中。它很好地填补了任何功能漏洞,并使转换变得简单——你所要做的就是基本的编译/打包过程,然后你可以在有时间的时候慢慢地从ant转移到构建的任何其他副作用上。 |
![]() |
16
1
文档越来越好,m2eclipse简直太棒了。但上面有人指出了“被设计破坏”的文章。他提出了一些很好的观点。虽然我个人认为maven是比ant更好的工具,但从长远来看,我们的经验将使maven3成为比maven2更好的工具。 我不能没有它。我可以去世界上任何有互联网连接的机器,JDK和Maven 2,查看我的git存储库,运行“mvn测试”,它就会构建。我敢对任何其他构建工具这么说。 :-) |
![]() |
17
0
我喜欢Maven,我一直在使用它。部分原因是,通过Eclipse的XML插件进行设置非常简单(它有一个非常描述性的XSD)。Maven也非常适合依赖关系管理,因为它允许您从存储库下载jar,并在适用的情况下排除可传递的依赖关系。它还有一个内置的网站:网站目标,非常适合制作具有适用报告的项目网站。 Maven非常适合刚刚开始的项目,但它确实有其预期的源代码格式。如果你用Maven开始你的项目,知道它能立即做什么,这将对你有很大的帮助。但你应该明确地研究一下。“开箱即用”,maven可以做很多很棒的事情,而且有很多插件。然而,有些事情ANT比Maven处理得更好,如果没有Maven插件,在Maven中可能很难处理。但是,你也可以学习创建自己的Maven插件。 看见 Better Builds With Maven 这是一个很好的maven指南。 哦,这些评论适用于Maven2,我从未使用过Maven1。 |
![]() |
18
-1
@MetroidFan2002:Maven1已被弃用,可以说它比Maven2更稳定(尽管功能更少)。写果冻剧本绝对是个坏主意。 yc公司 |