你对Maven有什么印象？

Question

我正在考虑将Maven用于我管理的Java开源项目。

然而，在过去，Maven并不总是拥有最好的声誉。你现在对Maven有什么印象？

Answer 1

对于一个开源项目，Maven有一些优势，特别是对于你的贡献者（例如mvn eclipse：eclipse）。

如果你选择Maven，你必须遵循的一条规则是：不要与工具作斗争。按照Maven建议的方式布置项目，遵循其所有约定和最佳实践。你与Maven进行的每一场小小的争斗都是你不会为你的项目编写代码的一天。

还要事先考虑要部署工件的位置（您是否要托管自己的存储库？）。

并且不要害怕使用Maven以外的其他东西（例如Ant）。项目本身的成功将是项目本身，而不是它的构建工具（只要你选择Ant和Maven都是最好的构建工具）。

Answer 2

就个人而言，我不是粉丝。我同意Charles Miller says about it being broken by design的大部分内容。它确实解决了一些问题，但它也introduces others。

Ant远非完美，但它更加健壮且记录得更好。它确实需要some discipline to use it in a modular way（这是Maven试图解决的问题之一）。我认为发明比Ant和Maven更好的东西并不会那么困难，但这个工具似乎还不存在。

如果你喜欢Maven的依赖管理而不是Maven，你可以使用Ivy在Ant中获得类似的东西。由于您无法控制的因素，我对此类依赖关系管理的问题是fragile。确实有意义的一个用例是，您的组织内部有许多相互依赖的项目。在这种情况下，一切都在你的控制之下，它可能会很好地运作。

编辑：我忘了补充说即使你不喜欢Maven，也不能忽视它。如果您编写其他人使用的开源库，他们会希望它们可以在Maven存储库中使用，以便他们可以从Maven构建中轻松使用它们。

EDIT2 ：由于您已经明确表示您的主要兴趣是为其他Maven用户提供开源库，因此值得注意的是，您不必使用Maven来实现这一目标。有a set of Ant Tasks for publishing to a Maven repository。因此，如果您想继续使用Ant来构建项目，您可以这样做，但仍然可以满足使用Maven的用户。

Answer 3

如果您的项目“简单”，那么maven可让您快速启动并运行。简单来说，我的意思是你有一堆代码，一些资源，一些测试类，所有这些都与一些第三方罐子一起制作一个应用程序。

当你想要以某种方式特定于自己的项目做一些不寻常的事情时，那么你最终会花费所有的时间来让maven做你想做的事，而没有时间来处理你的代码。这对我来说无法使用聪明的构建系统。

Maven在帮助您解决问题时也很可怕。构建脚本是不可读的不直观和不自然的xml的screeds，这当然可能是你喜欢和正在寻找的（如果你有ant-vision）。

我喜欢maven。 Maven充满了善良和承诺。我也讨厌maven。

修改

哦，日食的maven插件非常精彩。

Answer 4

当Maven从1.x过渡到2.x时，我不幸与Maven合作。它几乎消耗了我们一个更高级团队成员的100％的时间。我们最终取消了它。

然而，最近我有机会重新审视maven，我认为它已经有所改善。我的一个主要问题是缺乏良好的文档，但在阅读"Maven: the definitive guide"之后，我会说它更容易理解。

与eclipse的m2eclipse插件一起，管理依赖项变得轻而易举 - 它具有出色的依赖性可视化工具。

总的来说，我会说Maven是一个开始项目的好工具，但是一旦你的构建开始变得复杂，它可能会开始迷失方向。

Answer 5

关于maven有一些非常好的事情：

• Archetypes：一种很多人制作的启动（基础）项目（非常有用）。在那些倾向于一遍又一遍地重建同类东西的企业中，这是非常实用的。
• 依赖管理：你真的必须尝试去爱它。 Ivy也是一个很好的兼容工具。
• 生命周期管理：如果没有整个IDE，您可以使用maven命令行完成所有操作，我的意思是：编译，打包，测试，部署等等。并且可能会依赖其他步骤。虽然我认为默认值不是最好的，但这部分是可自定义的。

此外，maven还可以做一些蚂蚁。

对我来说，不利的一面是，很难将项目移植到它。最好从头开始。此外，maven广泛使用插件来完成它的工作，但并非所有内容都是完美的，并且还没有任何插件。

Answer 6

使用任何构建工具的主要原因之一是获得可重现的构建。也就是说，您今天所做的构建可以在几年内完全复制。根据我的经验，Maven在创建可重现的构建的测试中失败了。

这些问题源于一个拥有许多活动部件的大而复杂的野兽。每个部分都有自己的发布周期，版本经常相互冲突并破坏您的构建。试图调试这样的事情非常复杂。

我使用Maven进行开源工作，因为它可以相对快速地生成合理的网站。这是非开源开发人员很少感兴趣的东西。即使有这项任务，我也经常花费很长时间试图解决为什么事情没有按预期运作。对于开源工作，我通常使用ant实际生成构建（jar），因为它是可靠的。

最后一点。如果您正在编写一个开源项目，您可能 以某种方式使用Maven。如果您的项目很受欢迎，那么您需要在中央Maven存储库中获取它，如果您不使用Maven，这将更加棘手。

Answer 7

我个人非常喜欢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完成同样的工作）。

Answer 8

JavaPosse在recent podcast #217中讨论了Maven。大家一致认为，它在如何允许您构建项目方面具有非常严格的限制，但它的使用正在增长，并且它可能为表示项目提供跨IDE标准。

---

更新 -Javaposse还在去年春天的Java综述09中主持了一个信息丰富的会议，题为"Maven with Pain?"我笑了（以惊恐的同情），在录音结束时，其中一个参与者在生产发布前两天就插件更新如何破坏了他们的构建。

---

老实说，我已经避开它了，很大程度上是因为我觉得这个名字很烦人。但是，管理第三方库的依赖关系的能力很有吸引力。

---

更新 - 对于那些对我的非理性意见有不合理蔑视的人，让我告诉你“maven”在我脑海里想到的是什么：

是的，在我看来，Edna Mode是“maven”的 缩影。我不希望她在我的构建中 - 太专横！

什么是更好的名字？发明的单词最适合他们的针对性谷歌搜索结果。为了给人留下好印象，请用真实的词语将它们植根于一个积极的内涵。

Answer 9

我们有一个开源开发人员社区，他们独立完成自己的项目。其中一些项目使用其他项目的库。如果没有依赖关系管理，我们会在jar中遇到循环依赖关系。蚂蚁没有帮助解决这些问题（这是在Ivy之前，我没有使用过）。通过使用maven和部署jar，我们可以减少依赖关系并减少问题。因此，我们从拥有依赖管理工具中获益匪浅，而且我个人发现使用maven的努力非常值得。

Answer 10

使用Maven的一个主要好处是外部化'项目对象模型'（因此pom.xml）。这种独立项目结构的优势在于它可以跨工具和IDE进行移植。

所有主要IDE都在maven支持上投入了大量资金。当您在所选择的IDE中打开项目 时，它将采用Maven结构，您就可以开始了：

• 在Eclipse：导入... Maven项目......
• 在IntelliJ中：打开项目...浏览到pom.xml
• 在Netbeans：所有透明

您通常会将所有 IDE元数据（。iml，.project，.classpath等）放在 VCS忽略列表上。

显然，持续集成引擎以与基于POM的方法类似的方式受益。

有一个学习曲线并且存在约束，但是你得到了很多回报。

Answer 11

matt raible有一个博客文章http://raibledesigns.com/rd/entry/comprehensive_project_intelligence_with_jason。

我听说大多数使用maven的人都不喜欢它。

Answer 12

我们正在使用maven进行一个非常大的项目（超过15个模块），我们努力不打击这个工具，但是

1）maven解决了90％的常见问题，但是如果你在另外10％的问题上挣扎，那总是乱七八糟的

2）生命周期管理是一团糟。即使你为你的东西选择了一个正确的阶段，有时它也不起作用。你不知道为什么

3）我们努力奋斗但最终我们放弃了：我们使用来自maven的蚂蚁。有时我们甚至使用蚂蚁来调用maven。现在甚至不要认为我们很糟糕：如果只有你能看到我们构建过程中某些步骤的复杂性......那就是maven更经常地以你的方式构建复杂的项目。

4）本地存储库管理是一种负担。 Artifactory不好。和其他同类产品一样。

总而言之：我会建议Ant（如果你想要依赖管理，可能还有Ivy，但我从未尝试过）

再见 斯特凡诺

Answer 13

有些朋友告诉我，Maven有点像NetBeans：两者都遭受了某种耻辱，这种耻辱曾经应得但不再完全有效。由于缺少文档和XML / Jelly，我讨厌Maven 1.x.

后一个问题可能会得到解决，因为Maven 2更加面向Java。文件不好的耻辱仍然存在，但我不知道这是否公平。 （如果仍然公平，那么Maven团队真的放弃了球。）

POM和依赖管理都是很酷的想法，但人们想知道它们是否会被更新的工具所吸收，就像C ++引领新语言一样。

最后一点：Ant和Maven之间的二分法有些错误。 Gradle和Gant是Groovy空间中的构建工具，可以提供很多东西，即使对于直接的Java项目也是如此。因为它们使用Groovy，所以简单的任务非常简单（与Ant中令人痛苦的XML构造形成对比）;然而他们与Ant有很强的整合，所以有一套丰富的“硬”任务。

Answer 14

在我们公司，我们慢慢开始转向Maven，试图强化不同组件构建之间的一致性。现在，这是一个巨大的蚂蚁脚本混搭，试图做同样的事情。它运行良好，与我们的构建服务器（Hudson）很好地集成，以及Maven不支持（或完全支持）我们需要做的一些事情，我们基本上抛出了一个简化的ant build xml，我们附加到构建过程。它可以很好地插入任何功能漏洞并进行转换 - 所有你必须工作的是基本的编译/打包过程，然后你可以慢慢地从ant慢慢移动你的构建的任何其他副作用。

Answer 15

文档越来越好了，m2eclipse简直太棒了。但上面的人指出了“破坏设计”的文章。他提出了一些好点。虽然我个人认为maven是比ant更好的工具，但从长远来看，我们的经验将使maven3成为比maven2更好的工具。

没有它我就活不下去。我可以通过互联网连接，JDK和Maven 2去世界上的任何机器，查看我的git存储库，并运行'mvn test'，它将构建。说到任何其他构建工具，我敢说你。 ： - ）

Answer 16

Maven可用于管理项目的整个生命周期，从开始到部署。如果那些是你需要的，那么Maven就是正确的工具。如果您只是在寻找依赖管理工具，您可能也想查看Ant's Ivy。

它已经在我工作的大部分项目中使用过..虽然有时候很烦人（配置和文档），但它为我节省了很多时间。大多数Apache的基于Java的项目都使用Maven。

Maven是否有效，这实际上取决于你想要它为你做什么。

YC

Answer 17

我爱Maven，我一直都在使用它。部分原因是通过Eclipse的XML插件进行设置非常简单（它有一个非常具有描述性的XSD）。 Maven也非常适合依赖管理，因为它允许您从存储库下载jar并在适用的情况下排除传递依赖项。它还有一个内置的站点：站点目标，非常适合用适用的报告生成项目网站。

Maven非常适合刚刚开始的项目，但它确实具有预期的源代码格式。如果您使用Maven开始您的项目，知道它可以立即做什么，它将对您有很大帮助。但你应该明确地研究它。 “开箱即用”，maven可以做很棒的事情，并且插件很多。但是，有些东西比Maven更好处理，如果没有Maven插件，它可能很难在Maven中处理。但是，您也可以学习创建自己的Maven插件。

有关maven的良好指南，请参阅Better Builds With Maven。

哦，这些评论适用于Maven 2，我从未使用过Maven 1.

Answer 18

@ MetroidFan2002：Maven 1已被弃用，它可以说比Maven 2更稳定（尽管功能较少）。编写Jelly脚本绝对是一个坏主意。

YC