Java 为什么 Maven 的代表如此糟糕？

Why does Maven have such a bad rep?

提问by Dan

There is a lot of talk on the internet about how Maven is bad. I have been using some features of Maven for a few years now and the most important benefit in my view is the dependency management.

互联网上有很多关于 Maven 是多么糟糕的讨论。我使用 Maven 的一些特性已经有几年了，我认为最重要的好处是依赖管理。

Maven documentation is less than adequate, but generally when I need to accomplish something I figure it out once and then it works (for example when I implemented signing the jars). I don't think that Maven is great, but it does solve some problems that without it would be a genuine pain.

Maven 文档不够充分，但通常当我需要完成某件事时，我会想出一次然后它就可以工作了（例如，当我实现了对 jar 的签名时）。我不认为 Maven 很棒，但它确实解决了一些问题，如果没有它，这将是一个真正的痛苦。

So, why does Maven have such a bad rep and what problems with Maven can I expect in the future? Maybe there are much better alternatives that I don't know about? (For example, I never looked at Ivy in detail.)

那么，为什么 Maven 的代表如此糟糕，我可以期待未来 Maven 会出现什么问题？也许有我不知道的更好的选择？（例如，我从未仔细研究过 Ivy。）

NOTE: This is not an attempt to cause an argument. It is an attempt to clear the FUD.

注意：这不是试图引起争论。这是试图清除 FUD。

回答by Cuga

Maven is great. The reason for its reputation has got to do with the steep learning curve, in my opinion. (which I am finally close to getting over)

马文很棒。在我看来，其声誉的原因与陡峭的学习曲线有关。（我终于快要克服了）

The documentation is a bit rough to wade through, simply because it feels like there's a lot of text and new things to comprehend before it starts making sense. I say time is all that's needed for Maven to become more widely praised.

文档有点难以阅读，仅仅是因为在它开始变得有意义之前，感觉有很多文本和新事物需要理解。我说时间是 Maven 获得更广泛赞誉所需要的一切。

回答by Glenn

I wouldn't say it has a bad rep so much as it has a mixed rep. If your project follows the "convention over configuration" paradigm advocated by Maven then you can get a lot leverage out of it. If your project doesn't fit well into Maven's world view then it can become a burden.

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

To that end, if you have control over the project, then Maven may be the way to go. But if you don't and the layout is determined by someone not a fan of Maven, it may be more trouble than it's worth. The happiest Maven projects are probably the ones that started as Maven projects.

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

回答by Paul Sonier

I think Maven gets a bad rap because it imposes structure on your project, whereas other tools such as Ant allow you to completely define the structure any way you wish. Agreed also that the documentation is bad, but I think primarily the bad rap that Maven gets is because people are so used to Ant.

我认为 Maven 受到了不好的说唱，因为它对您的项目强加了结构，而其他工具（例如 Ant）允许您以任何方式完全定义结构。也同意文档很糟糕，但我认为 Maven 获得的坏名声主要是因为人们太习惯于 Ant。

回答by Apocalisp

Because Maven is a device for reducing grown men to sobbing masses of absolute terror.

因为 Maven 是一种将成年男子降低为绝对恐怖的啜泣群众的装置。

回答by Ben Turner

We use maven2 in all our projects and it speeds up development tenfold (combined with a nice continuous integration platform).

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

The only feature of maven2 that has caused us a lot of headaches in the past is the transitive dependency mechanism. In a Utopian world it would be the end-all solution to all dependency issues but in practice it tends to send you straight to dependency hell.

过去 maven2 唯一让我们头疼的特性就是传递依赖机制。在乌托邦世界中，这将是所有依赖问题的最终解决方案，但在实践中，它往往会将您直接送入依赖地狱。

Our main problem came from the fact that various components in the default maven2 repository depend on different versions of the same library (i.e component1 and component2 both require a logging framework but component1 requires v1 and component2 requires v2).

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

To solve this we simply have our own local repository containing all the libraries we need. This allows us to ensure that all libraries we use that have their own dependencies depend on the same versions of other libraries.

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

回答by Alex

Good question. I've just started a large project at work and part of previous projects was to introduce modularity to our code-base.

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

I've heard bad things about maven. In fact, it's all I've ever heard about it. I looked at introducing it to solve the dependency nightmare we're currently experiencing. The problem I've seen with Maven is that it is quite rigid in its structure, i.e. you need to conform to its project layout for it to work for you.

我听说过关于 maven 的坏事。事实上，这就是我所听说过的。我考虑引入它来解决我们目前正在经历的依赖噩梦。我在 Maven 中看到的问题是它的结构非常僵化，即您需要符合其项目布局才能为您工作。

I know what most people will say - you don't have to conform to the structure. Indeed that's true but you won't know this until you're over the initial learning curve at which point you've invested too much time to go and throw it all away.

我知道大多数人会说什么——你不必遵守结构。确实如此，但直到您完成最初的学习曲线后，您才会知道这一点，此时您已经投入了太多时间去扔掉它。

Ant is used a lot these days, and I love it. Taking that into account I stumbled across a little known dependency manager called Apache Ivy. Ivy integrates into Ant very welland it's quick and easy to get basic JAR retrieval setup and working. Another benefit of Ivy is that it's very powerful yet quite transparent; you can transfer builds using mechanisms such as scp or ssh quite easily; 'chain' dependency retrieval over filesystems or remote repositories (Maven repo compatibility is one of its popular features).

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

That all said, I found it very frustrating to use in the end - the documentation is aplenty, but it's written in bad English which can add to frustration when debugging or attempting to work out what's gone wrong.

话虽如此，我发现最终使用它非常令人沮丧 - 文档很多，但它是用糟糕的英语编写的，这可能会在调试或尝试找出问题所在时增加挫败感。

I'm going to revisit Apache Ivy at some point during this project and I hope to get it working properly. One thing it did do was allow us as a team to work out what libraries we're dependent on and get a documented list.

我将在这个项目的某个时候重新访问 Apache Ivy，我希望它能够正常工作。它所做的一件事是让我们作为一个团队来确定我们所依赖的库并获得一个记录列表。

Ultimately I think it all comes down to how youwork as an individual/team and what youneed to resolve your dependency issues.

最后，我想这一切都归结到如何你作为个人/团队，什么工作，你需要解决你的依赖问题。

You might find the following resources relating to Ivy useful:

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

• Apache Ivy vs Maven 2 comparison
• Apache Ivy FAQ
• Apache Ivy feature list

• Apache Ivy 与 Maven 2 比较
• Apache 常春藤常见问题解答
• Apache Ivy 功能​​列表

回答by kgiannakakis

Maven is a software management tool that can boost your productivity. I believe that such a tool is essential for software development in a new era.

Maven 是一种软件管理工具，可以提高您的工作效率。我相信这样的工具对于新时代的软件开发是必不可少的。

However, Maven isn't appropriate for all code bases. If you need to support a large legacy code page, or you import code from a third party, then it would be better to avoid using. Maven expects things to be in a certain way (convention over configuration). If you are starting a new project, then this is more than fine. If, however, you have a full system you need to support, the lack of flexibility is a nightmare.

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

Another reason that people usually complain about maven is the steep learning curve. Also IDE integration is still not very mature. Apacheis offering two plug-ins for Eclipse. The one is "mature", the other one offers a new approach. I suppose the new wouldn't be needed if the first one was adequate.

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

Another, more serious complain about Maven, is the use of XML for doing programming job. Perhaps tools like Buildrare the way to go.

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

回答by jens

I think one major reason for the bad reputation is that maven2 solves several complex problems (build automation, dependencies, managing repositories) as a one shot solution. Therefore you have to face these tough problems while starting to use maven. So it is a kind of "kill the messenger"-effect.

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

Other approaches (e.g. ant+ivy) often do not give you the chance to blame one single tool for all the problems you encounter. It is more like "okay ant not really easy to get started, ivy has some issues. But at least we don't have to wrestle with maven!" Saying that one does not recognize that all these problems taken together do not differ too much from the issues you encounter when using maven. It just may be a litte bit easier to tackle one at a time. BTW, I set up a build system based on ant+ivy in the past months. And I am really glad I did not have to use maven2 ;-)

其他方法（例如 ant+ivy）通常不会让您有机会将遇到的所有问题都归咎于一个工具。更像是“好吧，蚂蚁上手并不容易，ivy 有一些问题。但至少我们不必与 maven 搏斗！” 说人们没有认识到所有这些问题加在一起与您在使用 maven 时遇到的问题没有太大区别。一次解决一个问题可能会容易一些。顺便说一句，我在过去几个月建立了一个基于 ant+ivy 的构建系统。我真的很高兴我不必使用 maven2 ;-)

回答by Kevin Peterson

I looked into maven about six months ago. We were starting a new project, and didn't have any legacy to support. That said:

大约六个月前，我研究了 maven。我们开始了一个新项目，没有任何遗产可以支持。那说：

• Maven is all-or-nothing. Or at least as far as I could tell from the documentation. You can't easily use maven as a drop-in replacement for ant, and gradually adopt more advanced features.
• According to the documentation, Maven is transcendental happiness that makes all your wildest dreams come true. You just have to meditate on the manual for 10 years before you become enlightened.
• Maven makes your build process dependent on your network connection.
• Maven has useless error messages. Compare ant's "Target x does not exist in the project y" to mvn's "Invalid task 'run': you must specify a valid lifecycle phase, or a goal in the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal" Helpfully, it suggests I run mvn with -e for more information, which means that it will print the same message, then a stack trace for a BuildFailureException.

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

A large part of my dislike for maven can be explained by the following excerpt from Better Builds with Maven:

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

When someone wants to know what Maven is, they will usually ask “What exactly is Maven?”, and they expect a short, sound-bite answer. “Well it is a build tool or a scripting framework” Maven is more than three boring, uninspiring words. It is a combination of ideas, standards, and software, and it is impossible to distill the definition of Maven to simply digested sound-bites. Revolutionary ideas are often difficult to convey with words.

当有人想知道 Maven 是什么时，他们通常会问“Maven 到底是什么？”，他们希望得到一个简短、扎实的回答。“嗯，它是一个构建工具或脚本框架”Maven 不仅仅是三个无聊、乏味的词。它是想法、标准和软件的组合，不可能将 Maven 的定义提炼为简单地消化掉一些声音。革命性的思想往往难以用语言表达。

My suggestion: if you can't convey the ideas with words, you should not attempt to write a book on the subject, because I'm not going to telepathically absorb the ideas.

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

回答by flybywire

I love Maven - it boosts productivity, and I am very happy that I am no longer using Ant (phew!)

我喜欢 Maven - 它提高了生产力，我很高兴我不再使用 Ant（呸！）

But if I could change things it would be:

但如果我可以改变一些事情，那就是：

1. Make pom.xmlfile less verbose
2. Make it easier to include .jars not from the repository.

1. 使pom.xml文件不那么冗长
2. 更容易地包含 .jars 而不是来自存储库。