使用 Maven 有哪些优点/缺点？
我想知道人们使用或不使用 Maven 的原因。我们即将将所有构建切换到 Maven 2，并且不需要太多的经验。
使用 Maven 2 的优点/缺点是什么，例如：
- 为什么要切换到 Maven？
- 为什么你扔掉maven并使用 还有别的东西吗？
- 造成了什么问题 给你解决？
- 造成了什么问题 你的原因？
谢谢你！
I would like to know the reasons people use or not use Maven. We are about to switch all our builds to Maven 2 and don't have to much experience with it.
What are the advantages/disadvantages of using Maven 2, stuff like:
- Why did you switch to maven?
- Why did you throw maven away and used
something else? - What problem did it
solve for you? - What problem did it
cause for you?
Thank you!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
到目前为止我不喜欢它。
当我使用 Maven 时，项目的构建时间会急剧增加。从 eclipse 上的几毫秒到一秒，甚至是最简单的 Maven 项目也需要超过 30 秒。
鉴于有这么多人喜欢它，我一定做错了什么，但到目前为止我似乎无法弄清楚为什么需要很长时间才能构建一个基于 Maven 的项目。
So far I dis-like it.
When I use maven the build time for a project goes up dramatically. From several ms to a second on just eclipse, to over 30 seconds for even the simplest maven project.
Given that so many people like it, I must be doing something wrong, but so far I cannot seem to figure out why it takes ages to build a maven based project.
我从 Maven 开始，并一直坚持下去。当我使用 Maven 构建项目时，我从来不会遇到缺少库、错误库版本等问题……它可以编译，可以运行。
库升级很简单（不像 Ant）。
Maven 提供了许多有用的插件。我使用 Maven 在 Hudson 上运行功能测试 - 它下载我的项目的最新版本，启动嵌入式数据库，注入 dbunit 数据集，在码头上部署应用程序，运行测试，呈现测试结果。
我不喜欢的一件事是将所有内容都放在一个文件中。然后我想不仅使用 XML 来指定配置。
I started with maven and I stay with it. When I build a project with maven I never have problems with missing libraries, wrong libraries versions, ... It compiles, it runs.
Libraries upgrade is simple (not like Ant).
Maven provides many useful plugins. I use maven to run functionality testing on hudson - it downloads newest version of my project, starts embedded database, injects dbunit dataset, deploys application on jetty, runs test, renders test results.
One thing I don't like is to have everything in one file. Then I would like to specify configuration not only using XML.
我同意马克的观点，这对于新建项目来说非常有用。在您的开发环境中启动并运行它会产生一些开销，但这是值得的。
我可能会补充一点，使用 Maven 的一个潜在危险是，如果您正在开发一个大型项目，那么维护存储库中的 jar 可能会变得困难。您最终可能会在 POM.xml 中使用多个不同版本的 jar。
与任何项目一样，请确保您有良好的策略和程序来将不同的 Jars 引入代码库。这些 jar 可以有不同的许可证，可能会将您的代码库暴露给开源世界。确保这些许可证经过您的审核。
I agree with Mark that it's great for greenfield projects. There is a bit of an overhead to get it up and running in your development environment, but it is well worth it.
I might add that a potential danger to using Maven is that if you are working on a large project, it may become difficult to maintain the jars in the repository. You can potentially end up using several different versions of jars in your POM.xml's.
As with any project, make sure that you have good policies and procedures in place for bringing in different Jars into your code base. These jars can have different licenses that may expose your code base to the open source world. Make sure these licenses are reviewed by your.
在过去四年左右的时间里，我在遇到的每个项目中都使用了maven，从私人小型项目到大型企业数十个模块的项目，我从未后悔过使用maven。
我已经使用 maven 构建了从标准 java JAR / WAR / EAR 项目到 flex / AIR 应用程序和 Linux RPM 的任何内容，委托给 Antrun 或 GMaven当没有 Maven 插件可用于给定情况时。
标准 Maven 生命周期的强大功能和舒适性，加上丰富的代码生成、文档、代码度量等可用插件（通常都很易于使用），使得 Maven 成为 Java 构建系统的唯一真正选择。
继续吧，抨击它，但在你发明更好的东西之前，我会继续使用它。
I have used maven in every project I have encountered over the last 4 years or so, ranging from private mini-projects to huge enterprise dozens-of-modules projects and I have never once regretted using maven.
I have built anything from standard java JAR / WAR / EAR projects to flex / AIR apps and Linux RPMs using maven, delegating to either Antrun or GMaven when no maven plugin was available for a given situation.
The power and comfort of the standard maven lifecycle combined with the abundance of available plugins for code generation, documentation, code metrics etc that are usually all easy to use makes maven the only real choice for java build systems.
Go ahead and bash it, but until you invent something better, I'll keep using it.
马文太棒了！
我没有太多的时间来抒情地抒情，但以下是我认为 Maven 的几个主要优点（排名不分先后）： 可
就缺点而言，人们常说您最好接受 Maven 默认设置和约定，并且最好在新建项目一开始就开始使用它。如果您想节省在 POM 中配置 XML 的时间，我会在一定程度上同意这一点。
我并不是一个真正的工具狂热者，但是在 Maven 之前使用过 Make 和 Ant，我真的看不出采用 Maven 的任何缺点。它是一个优质工具，并且可以真正节省时间。
Maven is fantastic!
I don't have as much time to wax lyrical as I would like, but here are my top few benefits of Maven, in no particular order:
In terms of downsides, it is often said that you are better off accepting the Maven defaults and conventions, and ideally starting to use it at the outset of a greenfield project. I would agree with this to a degree if you want to save time configuring XML in your POM.
I'm not really a tool zealot, but having used Make and Ant before Maven, I really can't see a single downside to adopting Maven. It's a quality tool and a real time saver.
使用 Maven 的巨大优势是它的存储库基础设施。这促进了第三方库共享的标准协议，并使团队能够更有效地协作，而无需被迫将所有内容签入同一源代码存储库（模块化构建）。
存储库管理器是免费的，我建议安装以下其中一项：
好消息是，您不必为了利用 Maven 基础设施的优势而被迫使用 Maven 构建代码。
我推荐 Maven 用于没有遗产需要捍卫的“绿地”项目。项目的开始通常是引入新技术的最佳时机，并且使用 Maven 的好处已有详细记录。亮点是标准化的构建流程和丰富的第三方插件。
ANT 项目可以重新设计，以便与使用 Maven 的团队进行互操作。正确应用 ivy 插件实际上可以简化 ANT 构建过程。 Ivy 能够通过从 Maven 存储库下载依赖项并随后发布构建工件来管理项目的类路径（就像 Maven“部署”一样）。
最后，ivy 被嵌入到其他构建工具中。例如新的构建工具，例如 Gradle、simple-build-tool 和开发系统，例如 Grails。因此，拥抱使用 Enterprise Maven 存储库并选择适合项目团队的构建工具。
The great advantage of using Maven is its repository infrastructure. This promotes standard protocols for the sharing of 3rd party libraries and enables teams to collaborate more effectively without being forced to check everything into the same source code repository (Modular builds).
Repository managers are freely available and I'd recommend installing one of the following:
The good news is that you're not forced to build your code using Maven in order to utllize the benefits of having a Maven infrastructure.
I recommend Maven for "Green field" projects without a legacy to defend. The start of a project is generally the best time to introduce a new technology and the benefits of using Maven are well documented. The high-lights being a standardised build process and a wealth of 3rd party plugins.
ANT projects can be re-engineered to inter-operate with teams using Maven. The ivy plugin, applied properly, can actually simplify the ANT build process. Ivy is able to manage the project's classpath by downloading dependencies from the Maven repository and afterwards publishing the build artifacts (Just like a Maven "deploy").
Finally ivy is been embedded into other build tools. Examples are new build tools like Gradle, simple-build-tool and development systems like Grails. So embrace the use of an Enterprise Maven repository and choose the build tool that is appropriate for the project team.