我正在考虑将 Maven 用于我管理的 Java 开源项目。
然而，在过去，Maven 并不总是享有最好的声誉。此时，您对 Maven 的印象如何？
JMan
问问题
5376 次
18 回答
37
对于一个开源项目，Maven 有一些优势，尤其是对于您的贡献者（例如 mvn eclipse:eclipse）。
如果您确实使用 Maven，那么您必须严格遵守的一条规则是：不要与工具抗争。完全按照 Maven 的建议布局您的项目，遵循它的所有约定和最佳实践。您与 Maven 的每一次小争执都是您不会花费在为您的项目编写代码的一天。
还要预先考虑要在哪里部署工件（您要托管自己的存储库吗？）。
并且不要害怕使用 Maven 以外的东西（例如 Ant）。您项目的成功将取决于项目本身，而不是其构建工具（只要您选择了同类最佳的构建工具，Ant 和 Maven 都是）。
于 2008-11-20T01:56:56.947 回答
29
就个人而言，我不是粉丝。我同意查尔斯米勒所说的大部分关于它被设计破坏的说法。它确实解决了一些问题，但也引入了其他问题。
Ant远非完美，但它更健壮，文档也更好。不过，以模块化方式使用它确实需要一些纪律（这是 Maven 试图解决的问题之一）。我认为发明比 Ant 和 Maven 更好的东西不会那么困难，但是那个工具似乎还不存在。
如果你喜欢 Maven 的依赖管理但不喜欢 Maven，你可以在 Ant 中使用Ivy获得类似的东西。我对这种依赖管理风格的问题是，由于您无法控制的因素，它很脆弱。它确实有意义的一个用例是，如果您的组织内部有很多相互依赖的项目。在这种情况下，一切都在您的控制之下，并且可能运行良好。
编辑：我忘了补充一点，即使你不喜欢 Maven，你也不能忽略它。如果您编写其他人使用的开源库，他们会期望它们在 Maven 存储库中可用，以便他们可以从他们的 Maven 构建中轻松使用它们。
EDIT2：由于您已经澄清您的主要兴趣是向其他 Maven 用户提供开源库，因此值得注意的是，您不一定必须使用 Maven 来实现这一点。有一组 Ant 任务用于发布到 Maven 存储库。因此，如果您想继续使用 Ant 来构建您的项目，您可以这样做，但仍然可以满足使用 Maven 的用户。
于 2008-11-20T12:59:24.880 回答
12
如果您的项目“简单”，那么 maven 可以让您快速启动并运行。简单来说，我的意思是你有一堆代码、一些资源、一些测试类，所有这些都与一些 3rd 方 jar 一起制作一个应用程序。
当您想要做一些不寻常的事情时，您将最终花费所有时间试图让 maven 做您想做的事情，而没有时间处理您的代码。这对我来说违背了使用聪明的构建系统的目的。
Maven 在不工作时帮助您诊断问题也很糟糕。并且构建脚本是不直观和不自然的 xml 的难以阅读的长篇大论，这当然可能是您喜欢和正在寻找的（如果您有 ant-vision）。
我爱行家。Maven 充满了善良和承诺。我也讨厌maven。
编辑：
哦，Eclipse 的 Maven 插件非常棒。
于 2008-11-20T10:59:20.193 回答
10
当 Maven 从 1.x 过渡到 2.x 时，我不幸使用了它。它几乎消耗了我们一位资深团队成员 100% 的时间。我们最终取消了它。
但是，最近我有机会重新访问 maven，我会说它已经改进了。我的主要问题之一是缺乏良好的文档，但在阅读“Maven：权威指南”之后，我会说它更容易理解。
与用于 eclipse 的m2eclipse插件一起，管理依赖项变得轻而易举——它具有出色的依赖项可视化工具。
总的来说，我会说 Maven 是一个很好的工具，开始于一个项目，但一旦你的构建开始变得复杂，它可能会开始迷失方向。
于 2008-11-20T10:26:41.647 回答
8
maven 有一些非常好的地方：
- 原型：很多人制作的一种启动（基础）项目（非常有用）。在您倾向于一遍又一遍地重新创建相同类型的东西的企业中，它非常实用。
- 依赖管理：你真的必须尝试它才能爱上它。Ivy 也是一个很好的兼容工具。
- 生命周期管理：如果没有完整的 IDE，您可以使用 maven 从命令行执行所有操作，我的意思是：编译、打包、测试、部署等。并且可以使某些步骤依赖于其他步骤。虽然我认为默认值不是最好的，但这部分是可定制的。
此外，maven 还可以做一些蚂蚁的事情。
对我来说，缺点是很难将项目移植到它上面。最好从头开始。此外，maven 广泛使用插件来完成其工作，但在这方面并非一切都是完美的，而且还没有适合所有东西的插件。
于 2008-11-20T00:54:43.657 回答
5
使用任何构建工具的主要原因之一是获得可重现的构建。也就是说，您今天所做的构建可以在几年内完全复制。以我的经验，Maven 在创建可重现构建的测试中非常失败。
问题源于具有许多活动部件的大型复杂野兽。每个部分都有自己的发布周期，并且版本经常相互冲突并破坏您的构建。尝试调试这样的事情非常复杂。
我将 Maven 用于开源工作，因为它相对较快地生成了一个合理的网站。非开源开发人员很少对此感兴趣。即使完成了这项任务，我也经常花费很长时间试图找出为什么事情没有按预期工作。对于开源工作，我通常使用 ant 来实际生成构建（jar），因为它是可靠的。
最后一点。如果您正在编写一个开源项目，您可能必须以某种方式使用 Maven。如果您的项目很受欢迎，那么您需要在中央 Maven 存储库中获取它，如果您不使用 Maven，这将更加棘手。
于 2008-11-20T09:24:05.173 回答
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 来完成）。
于 2008-11-26T05:04:49.610 回答
3
JavaPosse 在最近的播客 #217中讨论了很多 Maven 。共识是，它在允许您构建项目的方式上非常严格，但它的使用正在增长，并且它可能为表示项目提供跨 IDE 标准。
更新——Javaposse 还在去年春天的 Java 综述 09 上举办了一次信息丰富的会议，题为“Maven with Pain？” 我笑了（带着惊恐的同情），在录音快结束时，一位参与者谈到了插件更新如何破坏了他们的构建——在产品发布前两天。
老实说，我已经避开了它，很大程度上是因为我觉得这个名字很烦人。但是，管理第三方库依赖项的能力很有吸引力。
更新——对于那些对我的非理性观点有非理性蔑视的人，让我向你展示一下我脑海中的“maven”：
是的，在我看来，Edna Mode 是“maven”的缩影。而且我不想让她出现在我的身材里——太专横了！
什么是更好的名字？发明词最适合其精确的谷歌搜索结果。为了给人留下好印象，请将它们扎根于具有积极含义的真实文字中。
于 2008-11-20T00:07:06.653 回答
3
我们有一个开源开发人员社区，他们独立地从事自己的项目。其中一些项目使用来自其他项目的库。如果没有依赖管理，我们会在 jar 中遇到循环依赖。ant 对这些问题没有帮助（这是在 Ivy 之前，我没有使用过）。通过使用 maven 和部署 jar，我们正在设法减少依赖关系并减少问题。所以我们从依赖管理工具中受益匪浅，我个人发现使用 maven 的努力是非常值得的。
于 2009-03-07T21:01:24.410 回答
2
使用 Maven 的一个主要好处是它外部化了“项目对象模型”（因此pom.xml）。这种独立项目结构的优势在于它可以跨工具和 IDE 进行移植。
所有主要的 IDE 都在 Maven 支持上投入了大量资金。当您在您选择的 IDE 中打开项目时，它将采用 Maven 结构，您就可以开始了：
您通常将所有IDE 元数据（.iml、.project、.classpath 等）放在VCS 忽略列表中。
显然，持续集成引擎以类似的方式受益于基于 POM 的方法。
有一个学习曲线，也有限制，但你会得到很多回报。
于 2010-07-29T11:13:52.797 回答
1
Maven 可用于管理项目的整个生命周期，从开始到部署。如果这些是您所需要的，那么 Maven 就是正确的工具。如果你只是在寻找一个依赖管理的工具，你可能也想看看Ant 的 Ivy。
它已在我从事的大多数项目中使用过，并且.. 虽然有时很烦人（配置和文档），但它为我节省了很多时间。大多数 Apache 的基于 Java 的项目都使用 Maven。
Maven 是否有效，实际上取决于您希望它为您做什么。
yc
于 2008-11-20T00:44:14.897 回答
1
我们将 maven 用于一个非常大的项目（超过 15 个模块），我们努力不与该工具抗争，但
1) maven 解决了 90% 的常见问题，但如果你还在为另外 10% 的问题苦苦挣扎，那总是一团糟
2) 生命周期管理一团糟。即使你为你的事情选择了一个正确的阶段，有时它也不起作用。你不知道为什么
3）我们努力奋斗，但最终我们放弃了：我们使用来自 maven 的 ant。有时我们甚至用 ant 来调用 maven。现在甚至不要试图认为我们很糟糕：如果你能看到我们构建过程中某些步骤的复杂性……只是 maven 经常妨碍你构建复杂的项目。
4）本地存储库管理是一种负担。手艺不好。等同类产品。
总而言之：我建议使用 Ant（如果你想要依赖管理，可能会使用 Ivy，但我从未尝试过）
再见斯特凡诺
于 2008-11-20T09:50:09.207 回答
1
matt raible 有一个博客条目http://raibledesigns.com/rd/entry/comprehensive_project_intelligence_with_jason。
我听说大多数使用 maven 的人都不喜欢它。
于 2008-11-20T12:08:08.227 回答
1
一些朋友告诉我，Maven 有点像 NetBeans：两者都受到某种耻辱，这种耻辱曾经是应得的，但不再完全有效。由于缺乏文档和 XML/Jelly，我讨厌 Maven 1.x。
后一个问题可能会得到解决，因为 Maven 2 更加面向 Java。糟糕文档的耻辱仍然存在，但我不知道这是否公平。（如果它仍然公平，那么 Maven 团队真的丢球了。）
POM 和依赖管理都是很酷的想法，但人们想知道它们是否会被更新的工具吸收，就像 C++ 引领更新语言一样。
最后一点：Ant 和 Maven 之间的二分法有些错误。Gradle 和 Gant 是 Groovy 空间中的构建工具，可以提供很多功能，即使对于直接的 Java 项目也是如此。因为他们使用 Groovy，所以简单的任务真的很简单（与 Ant 中痛苦的 XML 构造相反）；但是它们与 Ant 的集成度很高，因此有一组丰富的“硬”任务。
于 2008-11-26T05:20:19.313 回答
1
在我们公司，我们已经慢慢开始转向 Maven，以尝试在不同的组件构建之间强制执行统一性。现在，它是一个巨大的 ant 脚本混搭，试图做同样的事情。它工作得很好，与我们的构建服务器（Hudson）很好地集成，我们需要做的一些事情 Maven 不支持（或完全支持），我们基本上已经加入了一个简化的 ant build xml，我们附加到构建过程。它很好地填补了任何功能漏洞，并使转换变得简单——你所要做的就是基本的编译/打包过程，然后你可以在有时间的时候慢慢地从 ant 中转移构建的任何其他副作用。
于 2009-07-02T04:36:28.310 回答
1
文档越来越好，m2eclipse 简直太棒了。但是上面有人指出了“被设计破坏”的文章。他提出了一些好的观点。虽然我个人认为 maven 是比 ant 更好的工具，但从长远来看，我们的经验会让 maven3 成为比 maven2 更好的工具。
没有它我活不下去。我可以通过互联网连接、JDK 和 Maven 2 访问世界上任何一台机器，查看我的 git 存储库，然后运行“mvn test”，它就会构建。我敢说任何其他构建工具。:-)
于 2009-07-27T20:56:18.487 回答
0
我喜欢 Maven，我一直都在使用它。部分原因是通过 Eclipse 的 XML 插件进行设置非常简单（它有一个非常具有描述性的 XSD）。Maven 也非常适合依赖管理，因为它允许您从存储库下载 jar 并在适用的情况下排除传递依赖。它还有一个内置的 site:site 目标，非常适合生成带有适用报告的项目网站。
Maven 非常适合刚刚开始的项目，但它确实具有您预期的源代码格式。如果您使用 Maven 开始您的项目，并且知道它可以立即做什么，它将对您有很大帮助。但是你应该明确地研究它。“开箱即用”，maven 可以做很多伟大的事情，并且它的插件比比皆是。但是，有些东西 ANT 比 Maven 处理得更好，如果没有 Maven 插件，它可能很难在 Maven 中处理。但是，您也可以随时学习创建自己的 Maven 插件。
有关 Maven 的良好指南，请参阅Better Builds With Maven。
哦，这些评论适用于 Maven 2，我从未使用过 Maven 1。
于 2008-11-20T01:26:39.553 回答
-1
@MetroidFan2002：Maven 1 已被弃用，它可以说比 Maven 2 更稳定（尽管功能更少）。写果冻脚本绝对是个坏主意。
yc
于 2008-11-20T01:33:57.523 回答