为什么是行家?有什么好处? [英] Why maven? What are the benefits?

查看:23
本文介绍了为什么是行家?有什么好处?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

与使用 ant 相比,使用 maven 的主要好处是什么?它似乎比一个有用的工具更令人烦恼.我使用 maven 2、纯 Eclipse Java EE(没有 m2eclipse)和 tomcat.

What are the main benefits of using maven compared to let's say ant ? It seems to be more of a annoyance than a helpful tool. I use maven 2, with plain Eclipse Java EE (no m2eclipse), and tomcat.

maven 的支持者认为

Supporters of maven believe that

  1. Maven 可让您轻松获取包依赖项

  1. Maven lets you get your package dependencies easily

Maven 强制你有一个标准的目录结构

Maven forces you to have a standard directory structure

以我的经验

  1. 搞清楚包的依赖关系真的没有那么难.反正你很少这样做.可能在项目设置期间一次,在升级期间可能更多.使用 maven,您最终将修复不匹配的依赖项、编写糟糕的 poms 以及无论如何都要进行包排除.

  1. Figuring out package dependencies is really not that hard. You rarely do it anyway. Probably once during project setup and few more during upgrades. With maven you'll end up fixing mismatched dependencies, badly written poms, and doing package exclusions anyway.

缓慢的修复-编译-部署-调试循环,这会降低生产力.这是我的主要抱怨.您进行更改,您必须等待 maven 构建启动并等待它部署.没有任何热部署.

Slow FIX-COMPILE-DEPLOY-DEBUG cycle, which kills productivity. This is my main gripe. You make a change, the you have to wait for maven build to kick in and wait for it to deploy. No hot deployment whatsoever.

还是我做错了?请指出我正确的方向,我全神贯注.

Or am I just doing it wrong ? Please point me to the right direction, I'm all ears.

推荐答案

搞清楚包的依赖关系真的没有那么难.反正你很少这样做.可能在项目设置期间一次,在升级期间可能更多.使用 maven,您最终将修复不匹配的依赖项、编写糟糕的 poms 以及无论如何都要进行包排除.

Figuring out package dependencies is really not that hard. You rarely do it anyway. Probably once during project setup and few more during upgrades. With maven you'll end up fixing mismatched dependencies, badly written poms, and doing package exclusions anyway.

没那么难……对于玩具项目.但是我从事的项目有很多,真的很多,我很高兴能够传递它们,为它们制定标准化的命名方案.手动管理所有这些将是一场噩梦.

Not that hard... for toy projects. But the projects I work on have many, really many, of them, and I'm very glad to get them transitively, to have a standardized naming scheme for them. Managing all this manually by hand would be a nightmare.

是的,有时您必须处理依赖项的收敛.但是仔细想想,这不是 Maven 固有的,这是任何使用依赖项的系统所固有的(我在这里谈论的是一般的 Java 依赖项).

And yes, sometimes you have to work on the convergence of dependencies. But think about it twice, this is not inherent to Maven, this is inherent to any system using dependencies (and I am talking about Java dependencies in general here).

所以对于 Ant,你必须做相同的工作,除了你必须手动完成所有事情:获取项目 A 的某个版本及其依赖项,获取项目 B 的某个版本及其依赖项,弄清楚他们使用的确切版本,检查它们是否重叠,检查它们是否不兼容等.欢迎来到地狱.

So with Ant, you have to do the same work except that you have to do everything manually: grabbing some version of project A and its dependencies, grabbing some version of project B and its dependencies, figuring out yourself what exact versions they use, checking that they don't overlap, checking that they are not incompatible, etc. Welcome to hell.

另一方面,Maven 支持依赖管理,并将为我传递检索它们,并为我提供管理复杂性所需的工具依赖管理固有的:我可以分析依赖树,控制传递依赖中使用的版本,排除其中一些如果需要,控制跨模块的收敛等.没有魔法.但至少你有支持.

On the other hand, Maven supports dependency management and will retrieve them transitively for me and gives me the tooling I need to manage the complexity inherent to dependency management: I can analyze a dependency tree, control the versions used in transitive dependencies, exclude some of them if required, control the converge across modules, etc. There is no magic. But at least you have support.

并且不要忘记依赖管理只是Maven提供的一小部分,还有更多(甚至没有提到与Maven很好地集成的其他工具,例如声纳).

And don't forget that dependency management is only a small part of what Maven offers, there is much more (not even mentioning the other tools that integrates nicely with Maven, e.g. Sonar).

缓慢的 FIX-COMPILE-DEPLOY-DEBUG 循环,这会降低生产力.这是我的主要抱怨.您进行更改,您必须等待 maven 构建启动并等待它部署.没有任何热部署.

Slow FIX-COMPILE-DEPLOY-DEBUG cycle, which kills productivity. This is my main gripe. You make a change, the you have to wait for maven build to kick in and wait for it to deploy. No hot deployment whatsoever.

首先,你为什么要这样使用Maven?我不.我使用我的 IDE 编写测试、代码直到它们通过、重构、部署、热部署,并在我完成后运行本地 Maven 构建,然后再提交,以确保我不会破坏持续构建.

First, why do you use Maven like this? I don't. I use my IDE to write tests, code until they pass, refactor, deploy, hot deploy and run a local Maven build when I'm done, before to commit, to make sure I will not break the continuous build.

其次,我不确定使用 Ant 会让事情变得更好.根据我的经验,使用二进制依赖项的模块化 Maven 构建比典型的整体 Ant 构建提供了更快的构建时间.无论如何,请查看 Maven Shell 以准备(重新)使用 Maven 环境(这很棒方式).

Second, I'm not sure using Ant would make things much better. And to my experience, modular Maven builds using binary dependencies gives me faster build time than typical monolithic Ant builds. Anyway, have a look at Maven Shell for a ready to (re)use Maven environment (which is awesome by the way).

所以最后,我很抱歉地说,并不是 Maven 正在扼杀你的生产力,而是你滥用了你的工具.如果你对它不满意,好吧,我能说什么,不要使用它.就我个人而言,我从 2003 年开始使用 Maven,而且我从未回头.

So at end, and I'm sorry to say so, it's not really Maven that is killing your productivity, it's you misusing your tools. And if you're not happy with it, well, what can I say, don't use it. Personally, I'm using Maven since 2003 and I never looked back.

这篇关于为什么是行家?有什么好处?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆