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