Maven很酷。

Question

互联网上有很多关于Maven如何糟糕的话题。我已经使用Maven的一些功能已经有几年了，我认为最重要的好处是依赖管理。

Maven文档不够充分，但通常当我需要完成某些事情时，我会弄明白一次然后它就可以了（例如我实施签名时）。我不认为Maven是伟大的，但它确实解决了一些问题，如果没有它将是一个真正的痛苦。

那么，为什么Maven会有如此糟糕的代表，以及Maven在未来会遇到什么问题呢？也许还有更多我不了解的替代方案？（例如，我从未详细看过常春藤。）

注意：这不是导致争论的尝试。这是试图清除FUD。

Answer 1

大约六个月前，我看着maven。我们正在开始一个新项目，并没有任何遗产支持。那说：

Maven是全有或全无。或者至少从文档中我可以看出。你不能轻易使用maven作为ant的替代品，并逐渐采用更高级的功能。
根据文件记载，Maven是超凡的幸福，让你所有最疯狂的梦想成真。在你开悟之前，你只需要在手册上冥想10年。
Maven使您的构建过程依赖于您的网络连接。
Maven有无用的错误消息。将ant的“项目y中不存在目标x”与mvn的“无效任务'运行'进行比较：您必须指定一个有效的生命周期阶段，或格式插件中的目标：goal或pluginGroupId：pluginArtifactId：pluginVersion：goal”有帮助，它建议我用-e运行mvn以获取更多信息，这意味着它将打印相同的消息，然后是BuildFailureException的堆栈跟踪。

我不喜欢maven的很大一部分可以用以下来自Better Builds with Maven的摘录来解释：

当有人想知道Maven是什么时，他们通常会问“Maven究竟是什么？”，以及他们希望得到一个简短的声音答案。 “好吧，它是一个构建工具或脚本框架”Maven更多比三个无聊，没有吸引力的话语。它是思想，标准和软件的组合，它是不可能将Maven的定义提炼成简单的消化声音。革命的想法是通常很难用文字表达。

我的建议：如果你不能用文字传达这些想法，你就不应该试着写一本关于这个主题的书，因为我不会心灵感应地吸收这些想法。

Answer 2

从一开始就给你施加了严格的结构。
它是基于XML的，所以它和ANT一样难以阅读。
它的错误报告很模糊，当出现问题时会让你陷入困境。
文档很差。
让事情变得简单，简单易事。
维护一个Maven构建环境需要花费太多时间，这使得拥有一个全能的构建系统失败了。
需要很长时间才能发现你在maven中发现了一个错误并且没有配置错误。而且这些错误确实存在，并且存在于令人惊讶的地方。
它承诺了很多，但却背叛了你，就像一个美丽而诱人，但情感冷漠和操纵的情人。

Answer 3

我过去肯定bitched & moaned about maven。但现在，我不会没有它。我觉得这些好处远远超过任何问题。主要：

标准化的项目结构。
- 鉴于一位新开发人员加入了一个项目：
  - 当你说这是一个Maven项目时，开发人员知道项目布局以及如何构建和打包项目
  - 当你说它是一个Ant项目时，开发人员将不得不等待你解释更多或者必须通过build.xml来解决问题。
- 当然，总是可以用Ant强加公司范围的标准，但我想往往会重新发明众所周知的轮子。
依赖管理。
- 不仅适用于外部库，还适用于内部库/模块。请务必使用Maven存储库代理服务器，例如Nexus或Artifactory。
- 可以使用Ivy执行此操作。事实上，如果你只需要一个依赖管理，你可能最好使用Ivy。
特别是在一个项目中。我发现打破小子项目非常有用，maven处理得很好。蚂蚁要困难得多。
标准化工件管理（特别是与nexus或artifactory一起使用）
发布插件很棒。
Eclipse＆amp; NetBeans集成非常好。
与hudson的整合非常棒。特别是像findbugs这样的趋势图。
这是一个小问题，但是默认情况下，maven嵌入了版本号内部 jar或war（不仅仅是文件名）中的详细信息非常有帮助。

我的缺点主要是：

命令行非常无益。这让我开始了很多。
XML格式非常详细。我可以看出为什么这样做，但阅读仍然是一种痛苦。
- 也就是说，它有一个XSD，可以在IDE中轻松编辑。
一开始很难理解它。例如生命周期之类的东西。
- The definitive guide to maven是一个很好的介绍。

我真的相信花一点时间去认识maven是值得的。

Answer 4

我从两个大型项目获得的实践经验是，我们每个项目花费1000-1500小时来处理与maven相关的问题，不包括从maven 1到maven 2的500小时努力。

从那以后，我必须说我绝对讨厌maven。在思考它时我感到很沮丧。

Eclipse集成非常糟糕。（例如，我们在代码生成方面遇到了无穷无尽的麻烦，其中eclipse与生成的代码同步，并且经常需要完全重建。责备是maven和eclipse，但是eclipse比maven更有用并且说emacs，所以日食停留和maven必须去。）

我们有很多依赖项，正如我们发现的那样，语法错误实际上经常被提交给公共maven存储库，这可能会浪费你宝贵的时间。每周。解决方法是拥有代理或本地管理的存储库，并且花了很长时间才能做到正确。

Mavens项目结构不适合用Eclipse开发，并且eclipse中的构建时间也会增加。

代码生成和同步问题的影响，我们不得不经常从scrach重建，将代码/编译/测试周期减少到无休止的编译/ websurf / sleep / die / code-cycle，然后发送给你90s和40分钟的编译时间。

maven的唯一借口是依赖解析，但我想偶尔做一次，而不是每次构建。

总而言之，maven离KISS尽可能远。而且，当他们的年龄是一个主要的数字时，倡导者往往是那些在他们的生日庆祝额外的人。随意投票给我： - ）

Answer 5

Maven很棒。在我看来，其声誉的原因与陡峭的学习曲线有关。（我终于接近了）

文档有点粗糙，只是因为在它开始有意义之前感觉有很多文本和新事物需要理解。我说Maven需要的时间才能得到更广泛的赞誉。

Answer 6

因为Maven是一种减少成年男性啜泣绝对恐怖的装置。

Answer 7

我认为对于拥有最简单和最复杂项目的人来说，它的声誉很差。

如果您从单个代码库构建单个WAR，它会强制您移动项目结构并手动将三个罐中的两个放入POM文件中。

如果您正在从一组9个EAR文件原型中构建一个EAR，其中包含五个WAR文件，三个EJB和17个其他工具，依赖项jar和配置，需要在现有资源中调整MANIFEST.MF和XML文件。最终构建;那么Maven可能太受限制了。这样的项目变得混乱了复杂的嵌套配置文件，属性文件以及滥用Maven构建目标和分类器名称。

因此，如果你处于复杂性曲线的最低点10％，那就是它的过度杀伤力。在曲线的前10％，你穿着紧身衣。

Maven的增长是因为它适用于80％的中间

Answer 8

优点：

依赖管理。几年来，我和我的同事并没有手动下载和管理依赖项。这节省了大量时间。
IDE-独立性。事实证明，所有主要的IDE，Eclipse，IDEA和NetBeans如何得到Maven项目的良好支持，因此我们的开发人员不会被锁定在一个特定的IDE中。
命令行。使用Maven，支持同步IDE和命令行配置非常简单，有利于持续集成。

缺点：

必须投资学习Maven。好吧，必须这样做。好消息，不是团队中的每个人都要学习。
文档。曾经是一个问题，现在感谢Sonatype和他们的书（http://www.sonatype.com/products/maven/documentation/book-defguide），情况要好得多。
刚性。以你想要的方式做事有时会带来挑战和挫败感。我的建议是不要打架并让Maven做最好的事情，简单的构建，或者当有稳定的mojo时。在其他情况下，我们退出并使用Ant任务（http://maven.apache.org/plugins/maven-antrun-plugin/）orexternal程序执行操作。我个人最喜欢的是Groovy plugun（http://groovy.codehaus.org/GMaven）。

竞争：

Ant：没有依赖关系管理。周期。
常春藤：还不如Maven成熟（不是后者也没有它的怪癖）。几乎相同的功能集，所以没有令人信服的理由移动。我尝试了几次尝试;一切都不成功。

结论：我们所有的项目都已经用Maven完成了好几年了。

Answer 9

我的经历回应了许多帖子的挫败感。 Maven的问题在于它在寻求最终的自动化优势时包装和隐藏了构建管理的细节。如果它破裂，这会让你几乎无助。

我的经验是，maven的任何问题很快就会变成一个多小时的狙击，通过嵌套的xml文件网络，这种体验类似于根管。

我也曾经在严重依赖Maven的商店工作，喜欢它的人（喜欢它的“按下按钮，完成所有工作”方面）并不理解。 maven构建有一百万个自动目标，如果我觉得花时间阅读他们所做的事情，我肯定会有用。更好的2个目标，你完全理解。

警告：2年前最后一次与Maven合作，现在可能会更好。

Answer 10

像格伦一样，我不认为Maven有不好的代表，但是混合代表。我已经工作了6个月，专门尝试将一个相当大的项目项目迁移到Maven，它清楚地显示了该工具的限制。

根据我的经验，Maven很适合：

外部依赖管理
构建的集中管理（pom继承）
很多插件很多东西
与持续集成工具的非常好的集成
非常好的报告功能（FindBugs，PMD，Checkstyle，Javadoc，......）

它有一些问题：

全有或全无的方法（很难慢慢迁移到Maven）
complexe dependencies，intermodules dependencies
循环依赖（我知道，糟糕的设计，但我们无法修复5年的开发......）
连贯性（版本范围无处不在）
错误（同样带有版本范围）
可重现的版本（除非您修复所有插件的版本号，否则您无法确定将在6个月内获得相同版本）
缺乏文档（该文档对于基础知识非常有用，但是没有很多关于如何处理大型项目的示例）

为了给出一些背景信息，大约有30名开发人员在这个项目上工作，这个项目已经存在了5年多，所以：很多遗产，很多流程已经到位，许多自定义专有工具已经存在地点。我们决定尝试迁移到Maven，因为维护我们专有工具的成本太高了。

Answer 11

我想反驳一下本论坛的一些投诉：

Maven是全有或全无。或者至少从文档中我可以看出。你不能轻易使用maven作为蚂蚁的替代品，并逐渐采用更高级的功能。

事实并非如此。 Maven的最大胜利是使用它来以合理的方式管理你的依赖关系，如果你想在maven中做到这一点并在ant中做其他事情，你可以。方法如下：

<?xml version="1.0" encoding="UTF-8"?>
<project name="foo" basedir="." xmlns:maven="antlib:org.apache.maven.artifact.ant" >
  <maven:dependencies verbose="true" pathId="maven.classpath">
    <maven:pom id="maven.pom" file="pom.xml" />
  </maven:dependencies>
</project>

现在有一个名为“maven.classpath”的类路径对象，它包含pom文件中定义的所有maven依赖项。您只需要将maven ant任务jar放在ant的lib目录中。

Maven使您的构建过程依赖于您的网络连接。

默认依赖项和插件获取过程取决于网络连接，是的，但仅适用于初始构建（或者如果您更改正在使用的依赖项或插件）。之后，所有罐子都在本地缓存。如果你想强制没有网络连接，你可以告诉maven使用离线模式。

从一开始就强加于你的结构。

目前尚不清楚这是指文件格式还是“约定与配置”问题。对于后者，有许多不可见默认值，如java源文件和资源的预期位置，或源的兼容性。但这并不是刚性，它为您提供合理的默认值，因此您无需明确定义它们。所有设置都可以很容易地被覆盖（虽然对于初学者来说，在文档中很难找到如何更改某些内容）。

如果您正在谈论文件格式，那么在下一部分的回复中已经涵盖了......

它是基于XML的，所以它和ANT一样难以阅读。

首先，我不知道你怎么能抱怨某些方面的某些方面'并不比蚂蚁好'，因为它有一个不好的代表的理由。其次，虽然它仍然是XML，但XML的格式是很多更多的定义。此外，因为它如此定义，所以更容易为POM制作合理的胖客户端编辑器。我已经看过很长的蚂蚁构建脚本，这些脚本遍布整个地方。任何ant构建脚本编辑器都不会让它变得更加可口，只是以稍微不同的方式呈现的另一长串互连任务。

话虽如此，我在这里看到的一些投诉已经或有过一些无效，最大的抱怨

文档很差/缺失
可重复构建
Eclipse集成不好
错误

我的回答是双重的。首先，Maven是一个比Ant或Make更年轻的工具，所以你不得不期望它需要时间才能达到这些应用程序的成熟度。其次，如果你不喜欢它，修复它。它是一个开源项目并使用它，然后抱怨任何人可以帮助解决的事情对我来说似乎相当讽刺。不喜欢文档？有助于它使初学者更清晰，更完整或更容易获得。

可重现的构建问题分为两个问题，版本范围和自动maven插件更新。对于插件更新，除非您确定一年后重建项目时使用的是完全相同的JDK和完全相同的Ant版本，否则这就是使用不同名称的同一问题。对于版本范围，我建议使用一个插件，该插件将为所有直接和传递依赖项生成具有锁定版本的临时pom，并使其成为maven发布生命周期的一部分。这样你的发布构建poms总是对所有依赖项的精确描述。

Answer 12

它应该得到它的声誉。并非所有人都需要Maven开发人员认为适合每个项目的严格结构。它太不灵活了。对于许多人来说，依赖管理的“专业”是恕我直言，它是最大的“骗局”。我绝对不喜欢maven从网络下载jar并因不兼容而失眠（是的，离线模式存在，但那为什么我应该拥有所有那些数百个xml文件和校验和）。我决定使用哪些库，许多项目都严重关注依赖于网络连接的构建。

更糟糕的是，当事情不起作用时，你绝对会迷失方向。文档糟透了，社区无能为力。

Answer 13

一年后，我想更新一下：我不再对Maven社区有这样的看法。如果今天提出这个问题，我不会写这个答案。我将把我目前的意见添加为一个单独的答案。

这是一个非常主观的答案，但问题是关于意见，所以......

我喜欢Maven，我越了解它就越了解它。然而，影响我对它的感受的一件事是：maven社区主要围绕Sonatype（“maven公司”，它是许多Maven honchos工作的地方），而Sonatype正在积极推动其企业产品在社区中。 / p>

一个例子：“Maven Book”推特流链接到假定的introduction to repository management。

很抱歉，但“介绍”是Nexus的一半信息，一半销售。流行测验：除了Nexus和Nexus Pro之外，还有其他其他回购管理器吗？此外，这与所谓的开源Maven书有什么关系？哦，是的，关于存储库管理的章节已被分拆成一本单独的书......关于Nexus。呵呵。如果我为Maven书做出贡献，如果我的Nexus销售额增加，我是否会收到推荐费？

想象一下，如果您参与Java开发论坛，很明显Sun讨论Java的员工将抓住每一个可能的机会来讨论NetBeans和“NetBeans Pro”。过了一会儿，它失去了一些社区的感觉。我从来没有像Ant这样的经历。

说完所有这些之后，我确实认为Maven是一个非常有趣且有用的系统（我不称之为工具，比如Ant，Maven比那更广泛）用于软件开发配置和构建管理。依赖管理有时是一种祝福和诅咒，但它令人耳目一新 - 当然不是Maven提供的唯一优势。我可能对Sonatype先令的反应有点太强烈了，但在我看来，它会通过联想伤害Maven。我不知道这个意见是否被其他人所共享。

Answer 14

我认为Maven得到了糟糕的说唱，因为它在你的项目中强加了结构，而其他工具如Ant允许你以任何你想要的方式完全定义结构。同意文档很糟糕，但我认为主要是Maven得到的糟糕说唱是因为人们习惯了Ant。

Answer 15

因为不满意的人会抱怨而满意的人不会说他们感到满意。我的观点是，对maven用户的满意度远远高于未满足的用户，但后者会产生更多噪音。这实际上也是现实生活中常见的模式（ISP，电话运营商，传输等）。

Answer 16

魔法过多。

Answer 17

我对Maven的一些烦恼：

XML定义非常笨拙且冗长。他们从来没有听说过属性吗？
在默认配置中，它总是在每次操作时搜索'net。无论这对任何事情是否有用，对于“干净”都需要上网是非常愚蠢的。
再次在默认情况下，如果我不小心指定确切的版本号，它将从'net中提取最新的更新，无论这些最新版本是否引入依赖性错误。换句话说，你受到其他人的依赖管理的支配。
所有此网络访问的解决方案是通过添加-o选项将其关闭。但是如果你真的想要进行依赖关系更新，你必须记得把它关掉！
另一种解决方案是为依赖项安装自己的“源代码管理”服务器。惊喜：大多数项目已经有源代码控制，只有在没有额外设置的情况下才能运行！
Maven构建速度非常慢。摆弄网络更新减轻了这一点，但Maven构建仍然很慢。而且非常冗长。
Maven插件（M2Eclipse）与Eclipse集成最差。 Eclipse与版本控制软件和Ant相当顺利地集成。相比之下，Maven集成非常笨重和丑陋。我提到慢吗？
Maven仍然是马车。错误消息无益。太多开发人员正在遭受这种情况。

Answer 18

我认为Maven的代表不好，因为大多数批评者没有观察到Maven + Hudson + Sonar的组合。如果他们有，他们会问“我该如何开始”？

Answer 19

好主意 - 执行不力。

我最近将一个项目从Ant搬到了Maven。它最终运行良好，但我不得不在同一个pom中使用两个不同版本的maven-assembly-plugin和maven-jar-plugin（有两个配置文件），因为在一个版本中工作的东西在另一个版本中被破坏了。

所以非常头疼。文档并不总是很好，但我必须承认谷歌的答案相对容易。

确保始终指定您使用的插件版本。不要指望新版本会向后兼容。

我认为争议来自这样一个事实，即maven仍然在发展，而且这个过程有时是痛苦的。

问候

诉

Answer 20

我喜欢maven。我从1.0之前就开始使用它了。它是一个功能强大的工具，总的来说节省了大量的时间，并改善了我的开发基础架构。但我能理解一些人的挫败感。我看到了3种挫败感：

原因是真正令人担忧的问题（例如详细的POM，缺少文档），
有些是错误的信息（例如“你必须要建立互联网连接” - 不是真的 - 不要这样做，这可以避免），
其中一些是在maven发泄但实际上其他人是有罪的（“不要射击信使”）。

对于第一种情况，真正的问题 - 当然，有问题，POM很冗长，文档可能更好。尽管如此，有可能在短时间内与maven取得良好的效果。每次我使用ant构建项目时都会感到畏缩，并尝试将其导入到我的IDE中。设置目录结构可能需要很长时间。使用maven，它只是在IDE中打开POM文件的情况。

对于第二种情况，Maven是复杂的，误解是司空见惯的。如果maven 3可以找到一种方法来解决这种复杂性（甚至是感知到的复杂性），那将是很好的。 maven确实需要投入大量资金，但根据我的经验，投资可以快速收回成本。

最后一点，我认为对maven的传递依赖的抱怨可能是最着名的例子。

传递依赖性是使用重用的真实软件的本质。 Windows DLL，Debian软件包，java软件包，OSGi软件包，甚至C ++头文件都包含所有依赖项并遭受依赖性问题。如果你有两个依赖关系，并且每个都使用同一个东西的不同版本，那么你必须尝试以某种方式解决它。 Maven不会尝试解决依赖性问题，而是将其置于最前沿，并提供帮助管理问题的工具，例如通过报告冲突并为项目层次结构提供一致的依赖性，并实际上提供绝对控制项目的依赖关系。

手动包含每个项目的依赖关系的方法（一张海报说他将所有依赖关系检查到源代码控制中）冒着使用错误依赖关系的风险，例如更新库时忽略更新而不检查更新是否存在依赖关系。对于任何大小的项目，手动管理依赖项肯定会导致错误。使用maven，您可以更新您使用的库版本，并包含正确的依赖项。对于变更管理，您可以将旧的依赖项集（对于整个项目）与新集进行比较，并且可以仔细检查，测试任何更改等。

Maven不是依赖问题的原因，但使其更加明显。在处理依赖性问题时，maven使任何依赖性“调整”显式（对POM的更改覆盖依赖性），而不是隐式，就像在版本控制中手动管理的jar一样，其中jar只是存在，没有任何内容支持天气他们是正确的依赖关系。

Answer 21

对我来说，最重要的一个问题是Maven，如果配置不当，可能无法生成可重复的版本，原因如下：

不可靠的远程存储库;
对SNAPSHOT版本或没有版本的插件和库的依赖。

将这与蚂蚁构建形成鲜明对比 - 虽然啰嗦和令人讨厌的IMO - 因为所有的罐子都是在当地检查的。

好处是问题是可以解决的：

使用您自己的maven存储库，这已经变得简单，我正在使用Archiva并且效果很好;
始终正确地版本化您的依赖项。 Maven已经开始锁定超级POM中的插件版本，从2.0.8或2.0.9开始，所有依赖项都应该在已发布的版本上。

Answer 22

好问题。我刚刚开始了一个大型项目的工作，以前的项目的一部分是为我们的代码库引入模块化。

我听说过关于maven的坏话。事实上，这就是我所听说过的。我看着介绍它来解决我们目前正在经历的依赖性噩梦。我在Maven中看到的问题是它的结构非常严格，即你需要遵循它的项目布局才能为你工作。

我知道大多数人会说什么 - 你不必遵守结构。事实上这是真的但你不会知道这一点，直到你超过最初的学习曲线，此时你已投入太多时间去扔掉它。

Ant现在使用了很多，我喜欢它。考虑到这一点，我偶然发现了一个名为Apache Ivy的鲜为人知的依赖管理器。 Ivy集成到Ant 非常好，它可以快速轻松地获得基本的JAR检索设置和工作。常春藤的另一个好处是它非常强大而且非常透明;你可以很容易地使用scp或ssh等机制来传输构建;文件系统或远程存储库上的“链”依赖检索（Maven repo兼容性是其流行的功能之一）。

总而言之，我发现最后使用它非常令人沮丧 - 文档很多，但它是用糟糕的英语写的，这可能会在调试或试图解决出错的时候增加挫败感。

我打算在这个项目的某个阶段重新访问Apache Ivy，我希望能让它正常运行。它做的一件事就是让我们作为一个团队来确定我们所依赖的库并获得一个文档列表。

最终，我认为这完全取决于您如何作为个人/团队工作以及您需要解决您的依赖性问题。

您可能会发现以下与常春藤相关的资源很有用：

Answer 23

人们不喜欢Maven有很多原因，但让我们面对它们非常主观。 Maven今天提供了一些好的（和免费的）书籍，更好的文档，更多的插件和许多参考成功的项目构建，与一两年前的Maven不同。

在简单的项目中使用Maven非常容易，对于更大/更复杂的项目，需要更多的知识和对Maven理念的更深入理解 - 可能在公司层面上像Maven guru那样的网络管理员。 Maven讨厌陈述的主要来源通常是无知。

Maven的另一个问题是缺乏灵活性，例如：在蚂蚁。但记得Maven有一套惯例 - 在开始时坚持它们似乎很难，但最终往往会从问题中解脱出来。

Maven目前的成功证明了它的价值。当然没有人是完美的，Maven有一些缺点和怪癖，但在我看来，Maven慢慢地对抗他的对手。

Answer 24

我喜欢Maven - 它提高了工作效率，我很高兴我不再使用Ant（p！）

但如果我能改变一切，那就是：

使pom.xml文件更简洁
更容易将.jars包含在存储库中。

Answer 25

简短回答：我发现维护Maven构建系统非常困难，我想尽快切换到Gradle。

我和Maven一起工作了四年多。我称自己为构建系统方面的专家，因为在我参与的最后（至少）五家公司中，我对构建/部署基础架构进行了重大改造。

我学到的一些课程：

大多数开发人员往往不会花很多时间考虑构建系统;因此，构建变成了意大利面乱七八糟的黑客，但是当它们被清理和合理化时，他们确实很欣赏它。
在处理复杂性时，我宁愿有一个透明的系统来暴露复杂性（比如Ant），而不是试图通过强加严格的限制来简化复杂的事情，比如Maven。想想Linux与Windows。
Maven在功能上有很多漏洞需要拜占庭式的解决方法。这导致POM文件难以理解且无法维护。
Ant非常灵活且易于理解，但Ant文件也可以变得非常大，因为它的级别太低了。
对于任何重要项目，开发人员必须创建自己的构建/部署结构，超出工具提供的范围;结构对项目的适用性与维护的难易程度有很大关系。最好的工具将支持你创建一个结构，而不是打击你。

我稍微研究了Gradle，看起来它有可能成为两个世界中最好的，允许混合使用声明性和程序性构建描述。

Answer 26

我不会说它有一个糟糕的代表，因为它有一个混合代表。如果您的项目遵循Maven提倡的“约定优于配置”范例，那么您可以从中获得很多好处。如果你的项目不能很好地适应Maven的世界观，那么它就会成为一种负担。

为此，如果您可以控制项目，那么Maven可能就是您的选择。但如果你不这样做，并且布局是由不是Maven的粉丝决定的，那么它可能比它的价值更麻烦。最快乐的Maven项目可能就是那些以Maven项目开始的项目。

Answer 27

我一直在努力解决这里提到的大多数/所有负面问题，以及队友的类似异议，并且同意所有这些。但是我坚持下去并且将继续这样做，坚持只有一个目标，即只有maven（或者可能是gradle）真正实现的目标。

如果您正在为同行（开源开发人员）进行优化，那么ant / make /将会做什么。如果您要向非同行（用户）提供功能，则只能使用maven / gradle / etc。

只有maven允许您发布一小捆源代码+ poms（没有嵌入式lib /二进制依赖关系，包含神秘的名称和没有依赖关系信息），并且有一个记录良好的标准项目布局，任何IDE都可以由任何IDE加载没有吸收开发人员特有的布局惯例。还有一个按钮安装程序（mvn install），可以在获取任何缺少的依赖项的同时构建所有内容。

结果是一个简单的入口，用户可以按照这些内容进入代码，poms可以将其指向相关文档。

除了（不可或缺的）要求之外，我和任何人一样不喜欢maven。

Answer 28

如果您打算在开发项目上打赌您的业务或工作，您希望控制基础 - 即构建系统。使用Maven，你无法控制。它是声明性的和不透明的。 maven框架开发人员不知道如何构建透明或直观的系统，这从日志输出和文档中可以清楚地看出。

依赖关系管理非常诱人，因为它可能会在项目开始的某个时候与您相同，但会受到警告，它会从根本上被打破并最终会让您感到头疼。当两个依赖项具有不兼容的瞬态依赖关系时，您将被大鼠的复杂性嵌套所阻挡，这将破坏整个团队的构建并阻止开发数天。由于本地存储库的状态不一致，使用Maven的构建过程对于团队中的不同开发人员来说也是出了名的不一致。根据开发人员创建环境的时间或他们正在处理的其他项目，他们将得到不同的结果。你会发现你正在删除你的整个本地存储库并让Maven重新下载jar文件的次数远远超过dev分支的第一次设置。我相信OSGI是一个试图解决这个根本问题的倡议。我想说，如果事情需要如此复杂，那么基本前提就是错误的。

我已经成为超过5年的maven用户/受害者了，我不得不说，它将为您节省更多时间来检查您的源存储库中的依赖项并编写简单而简单的ant任务。使用ant，您可以确切地知道构建系统正在做什么。

由于Maven的问题，我在几家不同的公司经历了很多很多人。

我最近试图将一个旧的GWT / Maven / Eclipse项目恢复生机，以及我所有业余时间的2周后，我仍然无法让它始终如一地构建。现在是时候减少我的损失并使用蚂蚁/日食开发我认为......

Answer 29

它比你用来编写项目的语言更复杂。正确配置比实际编程更难。

Answer 30

对我来说，有很多专业人士使用maven vs ant进行内部项目。但是对于开源项目，我认为Maven在使许多项目更容易构建方面产生了很大的影响。不久前，需要花费数小时才能编译平均的OSS Java（基于ant）项目，不得不设置大量变量，下载依赖项目等等。

你可以用Maven做任何事情，你可以用Ant做什么，但是Ant不鼓励任何标准，Maven强烈建议你遵循它的结构，否则它会更多的工作。确实，使用Maven设置Maven很容易，但是最终的结果几乎总是从想要检查项目的人的角度来看更容易构建。

Answer 31

任何Java开发人员都可以轻松成为ANT的专家用户，但即使是专业的Java开发人员也无法成为初级MAVEN用户。

Maven会让您的开发人员因为执行与构建和部署相关的任何事情而感到害怕。

他们将开始尊重Maven而不是War文件或Ear文件!!哪坏是坏坏！

然后你将受到在线论坛的支配，粉丝男孩会因为你没有采用“Maven方式”而谴责你。

Answer 32

我区分Maven 1和2：前者有（当之无愧）坏名声;后者是一种改进和不断提升的“标准”。

我个人认为Maven 2比我喜欢的更复杂，更僵硬。一个人的标准是另一个人的直筒夹克。我同意上面的“太多魔术”评论。当我将Ant的简单性与Maven 2的复杂性进行比较时，我知道我更喜欢哪一个。

我承认我更了解Ant。我正在研究Maven 2，但我还没到那里。我的可怜见解可能会更多地说明我和我的知识状况，而不是Maven 2的真实价值。

Answer 33

我认为声誉不好的一个主要原因是maven2解决了一些复杂问题（构建自动化，依赖关系，管理存储库）作为一次性解决方案。因此，在开始使用maven时，你必须面对这些棘手的问题。所以它是一种“杀死信使” - 效果。

其他方法（例如ant + ivy）通常不会让您有机会为遇到的所有问题指责一个工具。它更像是“好吧蚂蚁不是很容易上手，常春藤有一些问题。但至少我们不必与maven搏斗！”说一个人没有意识到所有这些问题并没有与你在使用maven时遇到的问题有太大的不同。一次解决一个问题可能更容易。顺便说一下，我在过去几个月里建立了一个基于ant + ivy的构建系统。而且我很高兴我不必使用maven2; - ）

Answer 34

Maven说唱不好的最大原因是IDE集成。是的，我知道m2eclipse。我喜欢m2eclipse。我更喜欢Netbeans的整合。

这是问题所在。一些较大的商店建立了工具来迫使Maven使用RAD 7.0之类的东西。它不能很好地工作。存在这些hackarounds以试图让Maven在他们不允许更改的工具内行为（RAD 7.0）。在我的情况下，hackarounded maven只能在Netbeans内部工作。带有m2eclipse的Eclipse 3.5扼杀了一些可怕的东西。

这里的大多数开发者都讨厌Maven。他们不讨厌Maven。他们从未真正使用过Maven。

令人失望，但这并不是Maven的错。在另一个生命中，Maven对我的工作非常好。在这里，由于IDE和用于使其可用的工具无法实现，因此它使人衰弱。

Answer 35

我的回答：大多数用户抱怨maven是因为他们正在寻找专业人士，但他们没有时间（或者他们不想忍受）来建立他们的“公司环境”。这是个人选择，它可以取决于个人的耐心，工作环境（老板永远不会理解做得好的事情比永久的错误修复周期浪费更少的时间），等等。

但是，在下列情况下，您只能在工作站上使用maven而不会生气：

一个带有一些bean的简单库。
一场简单的“一体化”战争。
甚至是一个具有“标准”依赖关系的多模块项目（spring，hibernate，apache stuffs以及你在中央存储库中可以找到的任何内容）但是对你的库没有任何依赖。

当你想要更多的问题时，问题就会出现，例如创建标准框架类的包装器，或者可重用的组件库，你总是希望使用一组你喜欢的插件等。

在这种情况下你必须把时间花在学习上：我在之前的帖子中读到有人谈论浪费半天或两天......这还不够，根本就是：我们是谈论连续修改你的poms至少一个月。

如果你想在复杂的项目中使用maven，你应该按顺序：

有你的内部存储库：它不是一个选项，它是强制性的。我尝试了Artifactory和Nexus，他们可以在开始时制造麻烦但是当你设置它们时，你会忘记它们。
创建一个“主pom”，其中包含您需要的所有插件（指定相对版本），但如果您不想遇到麻烦，则必须避免将标准依赖项放在那里（对于那，请参阅dependenciesManagement中的scope = import）。这是最难的部分，但你可以开始复制一个着名项目（春天，挂毯，ecc ......）的主pom并剥离你不需要的东西。
如果你有一个复杂的项目，你必须在开始创建工件之前考虑你想要的东西。例如，在一个具有（war + WebServices Client）+（Webservice Server + spring + hibernate + Jbpm + whateverelse ....）的项目中，创建一个由客户端引用的“api”模块是个好主意。和服务器，但它只包含模型+接口，并没有在客户端和相反的情况下带来“服务器端”依赖。 失败，maven将成为地球上一个活生生的地狱。
如果你使用Eclipse，m2e插件是必不可少的：好吧，它可能很慢，有时你应该刷新项目并更新项目配置等...但是找到已经设置的“项目构建路径”是值得的一切。在最坏的情况下，命令行将始终有效。
虽然Continuous Integration服务器是可选的，但至少对您的公共库强烈建议。在Web上放置Web应用程序可能太多了（您不会在多个项目中重复使用Web应用程序），但将CI作为标准基类，“常用”实体bean等等是无价的。请记住，这些组件不仅仅由您使用，但是当您忙于代码的其他部分并且您可以忘记（我经常这样做）在公司存储库中手动部署它们时，它们甚至可以由您的团队成员使用可供团队成员使用。

要完成所有这些......好吧，你甚至可以在开始时花几个月，但是一旦你习惯了，你就会加快你的发展。

就我个人而言，我还没有使用Gradle，我不知道它是否比Maven更好或更差。

Answer 36

我的观点是基于约定优于配置的缺陷：

http://chriswongdevblog.blogspot.com/2011/01/trouble-with-being-conventional.html

我与Maven的问题在于发现的难度和无限的复杂性。那个，并且看着同事浪费半个工作日来对抗Maven构建问题。另外恕我直言，Maven与Eclipse的集成使事情变得更糟，因为你已经把出错的地方数量增加了。

Answer 37

Maven是一款可以提高工作效率的软件管理工具。我相信这样的工具对于新时代的软件开发至关重要。

但是，Maven并不适合所有代码库。如果您需要支持大型遗留代码页，或者从第三方导入代码，那么最好避免使用。 Maven希望事情以某种方式存在（约定优于配置）。如果你正在开始一个新项目，那么这很好。但是，如果你需要支持一个完整的系统，那么缺乏灵活性就是一场噩梦。

人们通常抱怨maven的另一个原因是陡峭的学习曲线。 IDE集成还不是很成熟。 Apache为Eclipse提供了两个插件。一个是“成熟”，另一个提供了一种新方法。我想如果第一个足够的话就不需要新的。

另一个更严重的抱怨Maven的是使用XML进行编程工作。也许像Buildr这样的工具是可行的。

Answer 38

好吧，我不太了解Maven的细节，但是我试图让它比我想承认的更多次。对我来说使用Maven很简单：
你需要“聘请”一位特殊的Maven大师，你不需要蚂蚁;否则请你的开发人员花时间学习如何“建立”他们的工作，而不是倾向于如何“做”他们的工作如果你想真正了解它，你需要“购买”他们出售的书。

然后：
它基本上只解决了一个真正的问题“依赖关系”我想知道有多少项目依赖于许多其他项目，他们需要一个特殊的工具来解决它们的依赖关系？而ANT不能这样做吗？
。我个人不会盲目地升级到更新版本的开源框架而不需要这样做。如果它正常工作则不要修复它，对吧？

但那么这是主观的吗？

Answer 39

Maven防守者常说“嗯，你只是不明白”。他们认为，这是一个真正的快速反驳。

它是这样的：

超级程序员： “嘿，我需要打开这扇门，有没有人有门挡” Maven程序员： “为什么是，这是一个”（向他展示一系列复杂的冰棒）超级程序员： “这些棍子没有把门打开！” Maven程序员（踌躇满志，轻笑）： “你只是不理解它。我建议你阅读手册，并且真正研究这个东西大约1年!!!”

Answer 40

Maven不尊重KISS原则。尝试做除mvn clean install之外的任何事情你都遇到了麻烦。有了蚂蚁，你可以随心所欲地做任何事情。

Answer 41

Maven不容易支持非标准操作。有用插件的数量虽然在不断增长。 Maven和Ant都不容易/本质上支持Make的文件依赖概念。

Answer 42

Maven确实解决了工作问题，它构建了java软件，并且易于依赖管理。但它与Ant，GNU Make或其他类Unix包管理系统有很大不同。这使新来者不得不花很多钱去学习它。

有很多Maven文档，但其中一些推送你，就像“使用m2eclipse”一样：

只需在查询字段中输入groupId，m2eclipse就会查询存储库索引，甚至会显示当前在我的本地Maven存储库中的工件版本。此选项是首选，因为它节省了大量时间。

我真的不想弄出一个长句，发现它什么也没说。我记得在阅读python官方教程和erlang的时候有多好。好的文件会表明作者有很好的感官。

Maven对新手来说显得很奇怪，它的命令行风格与Unix命令行传统不同。如果您花时间浏览“maven by examples”或“The Definitive Guide”，它会得到回报，您可以在http://www.sonatype.com/找到它。但即使您阅读了所有这些文档，并且可以放心使用该工具，您也可能会遇到麻烦，有些是由软件错误引起的。专家可以通过这种方式获得并保持高效。

毕竟，Maven是开源软件，它为自由工程师提供知识。这使它尊重。当人们更多地谈论它的糟糕声誉时，它正在为开源世界做好工作。

因此，正如熟练的人使用任何工具一样，只需使用它，而不是依赖它，依靠自己。

Answer 43

已经提到的“全有或全无”方法是我通常使用Ant的原因......更常见的是你开始研究一个“遗留”项目，它已经有了一个已定义的结构，你可以不要因为Maven想要别的东西而改变。

另一方面，Ant可以随时使用，无论项目是否解体。

关于替代方案，我读过关于rake的好东西。

（顺便说一下，我说的是Maven 1，还没看过Maven 2）

Answer 44

我们在所有项目中使用maven2，它将开发速度提高了十倍（与一个不错的持续集成平台相结合）。

maven2的唯一特征在过去引起了很多麻烦，那就是传递依赖机制。在乌托邦世界中，它将成为所有依赖性问题的最终解决方案，但在实践中，它往往会直接导致您依赖地狱。

我们的主要问题来自于默认maven2存储库中的各个组件依赖于同一个库的不同版本（即component1和component2都需要一个日志框架，但component1需要v1而component2需要v2）。

要解决这个问题，我们只需拥有自己的本地存储库，其中包含我们需要的所有库。这使我们能够确保我们使用的所有具有自己依赖关系的库都依赖于其他库的相同版本。

Answer 45

很简单，Maven想拥有这个世界。它想要定义项目，它们如何在文件系统上布局，罐子放在其可爱的本地缓存中，如何获取东西，依赖图，构建插件，ide插件等等。

有些人喜欢那种东西，敬佩它。对我来说，这完全取决于质量，我不太关心你的boooooring理论。只要执行，完美无瑕，然后最好淡入背景，直到我决定再次与你混淆。

我向Sonatype和Maven的追随者/辩护者发出的信息是，你还没有质量渗透。 pom.xml格式太冗长，学术性和繁琐 - 修复它。复杂的多项目构建使Maven设置变得令人抓狂 - 为什么这么难？微调什么时候拿取以及什么时候不拿取未指定的罐子将是一件有趣的事情 - 直到我们得到它，只要我们能够/我们认为我们想要的东西就会令人抓狂。 SNAPSHOT总是全都戴帽子，因为它尖叫/嘲笑我并让我发疯？小巧和愚蠢/独特的方式肮脏的开源maven插件插入poms是令人发狂的。类路径问题没有解决它们的好方法？哦，是的，传统的apache commons- * groupId污染了我的存储库根本是令人抓狂的“奶酪三角形不那样！” - 愤怒的方式。 m2eclipse是纯粹的集中疯狂，死亡怪物死亡，用火杀死它是我们可以肯定的唯一方法。

Maven一次让我对一个客户感到尴尬 - 一个工具阻碍了我的工作，这是不可原谅的！我希望我的工具（和他们的制造者）像他们那些卑微的仆人一样行事。当我向Maven询问国王是谁时，我希望答案是“DAVE”，然后是愉快和鞠躬！：）

惯性是Maven的真实故事。如果你想玩开源java，你几乎可以从Maven存储库中获取。所以，如果你想在那里玩得很好，你最好能够以Maven的方式获得你的依赖，并学习阅读poms ...感谢Ivy和IvyDE，我可以在Ant和Eclipse中设置我的maven依赖项。不要被Maven工具链困住。

我使用的Maven存储库服务器软件就像Nexus和Artifactory一样，是一个简洁，未来的工具。与其他的maven生态系统相比，它们是闪闪发光的珠宝。

我的Maven体验感觉就像Eclipse在当天的感受。 Eclipse想要以他们愚蠢的想法拥有这个世界，并且在我真正允许Eclipse拥有我的世界之前，平台需要很长时间才能成熟，多年和多年。也许在多年和几年Maven可以达到这样的质量水平？在这一点上，我说“再也不会让我的眼睛看到恐怖了”，但是当它出现时我也在谈论Eclipse 1.0。：）

Answer 46

Maven很酷。

不要再听取其他选择，因为现在还没有 - 这些都不是玩具。

除了微软开发工具链 - 它是金钱无法购买的最佳技术。

所有这些试图推动＆＃39; 工具链的人＆＃39; - 它只是一种廉价的尝试，可以播下混乱并抓住市场份额。

讨厌仇恨。

SBT

地球历史上最大的误称。你的Build能否通过图灵测试？他妈的很荒谬，10年前的一个荒谬的DSL。使用IVY依赖管理，Maven的中间兄弟。

ANT

从Shockwave开发毕业后的第一个项目非常棒。

你理解XML，并且热情，但不是真正了解构建阶段，6个月后重新启动项目，为什么版本控制二进制文件是一个虚假的万能药，或者有一天以外的人会尝试工作与您的项目。

MAKE

如果整个世界都在同一个UNIX终端上运行，并说流利的Bash，那么是的。但是，为什么不成为一名C / C ++程序员，无论如何它都比Java更有趣。

Ruby（各种）

无论。利基，慢。然后开发Ruby，远离Java开发。

的Python

人们使用Java而不信任Python（任何涉及到资金的地方）。如果你的系统正在运行Python，你甚至不会读这个，除非你当然想要Java资金 - 但是在一些网上商店中却不能开发Python。

Clojure（各种）

为了纪念Stallman，我将学习Lisp - 但是对于Emacs而言，我并不是在我的VM上运行它。我觉得它让这次经历变得很糟糕。

Answer 47

优点：

当您需要快速启动并且依赖关系管理良好时，Maven非常棒。避免jar-hell的设施也不错。 Maven背后的一些潜在理论是合理的。对于任何想要学习构建工程最佳实践的人来说，默认的生命周期阶段都经过深思熟虑并且非常有启发性。尽管文档很差，可发现性非常好，但请尝试mvn help：help -Ddetail = true以查看我的意思。如果您知道如何阅读xsd文档，那么构建一个pom就不那么难了。

缺点（魔鬼在细节中）：

无法指定绑定到同一阶段的不同插件执行的顺序，计算机编程中的任何形式的非确定性都非常糟糕。

与Ant属性值不同，即$ {my.property}，Maven属性在构建开始时被解析，如果您知道该值在开始时将是什么，但是如果在某处确定属性的值，则可以。在构建过程中，访问它已经太晚了，它在分配之前已经被解释，因此值将为null或空字符串。甚至在需要属性的执行在分配属性的执行之后的阶段中执行时也是如此 - ＆gt;把头发撕成了这个。

如果坚持“Maven方式”，一切都会顺利进行。一旦你的构建从“Maven方式”离开，所有地狱都会崩溃 - ＆gt;我希望能够很好地为您的项目编写定制的Maven插件和原型，因为从头开始这样做比围绕Maven的约束更有效。

当使用聚合（Maven-speak中的模块）和继承（Maven-speak中的父模块）处理包含许多pom文件的大型项目时，在构建相同或类似事物的构建中存在太多重复。 Maven xml语法没有明确的方法来区分那些将从父级继承的成员和那些不会从父级继承的成员。期望每两分钟运行一次mvn help:effective-pom来解决这个问题。

具有许多插件配置的复杂构建变得臃肿且难以理解。这是xml比Maven本身更多的问题。编写构建的方式更清晰，更具表现力 - ＆gt;例如支持元编程的动态语言中的内部DSL，即Gradle，Buildr

简介：强大的力量带来了巨大的责任。坚持构建本身内部各自部署环境中的配置太容易了，这违反了“一个二进制”原则。配置文件应该被设计为强调“角色”而不是环境，即从CI部署到分段而不是持有分段本身的配置的行为。

Answer 48

好吧，我现在和maven一起浪费了2天。使用m2eclipse，我发现eclipse中报告的依赖项在存储库中缺失，就像那样。当我尝试IAM并想为struts 2生成一个简单的空白项目时，我发现v2.0.9也已从存储库中删除。当我最终手动添加工件和东西时，项目创建自己只是为了发现无论我要求IAM做什么，它都会响应：没有发现maven 2项目.....嘿，我不是只使用Maven 2项目向导???从第一天开始，Maven一直很痛苦。它背后的想法非常好。但实际上，它缺乏所有相关方的纪律。而这使它几乎一文不值。因为今天您的项目可能会建立。明天，当一些笨蛋从某些回购中删除了一些pom时，你就搞砸了。就如此容易。它不适用于专业的企业发展！一点也不。也许在一年或五年？

为什么Maven有这么糟糕的代表？

48 个答案:

Maven很酷。

讨厌仇恨。