qq_27836205
Jordan裔
2017-05-10 03:46
采纳率: 71.7%
浏览 6.4k
已采纳

为什么要使用maven 使用maven有什么好处

为什么要使用maven 使用maven有什么好处。。。。。。。

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 邀请回答

5条回答 默认 最新

  • cgt_0812
    cgt_0812 2017-05-10 07:20
    已采纳
      1. maven不仅是构建工具,它还是依赖管理工具和项目管理工具,提供了中央仓库,能够帮我们自动下载构件。
    
        2.为了解决的依赖的增多,版本不一致,版本冲突,依赖臃肿等问题,它通过一个坐标系统来精确地定位每一个构件(artifact)。
    
        3.还能帮助我们分散在各个角落的项目信息,包括项目描述,开发者列表,版本控制系统,许可证,缺陷管理系统地址。
    
        4.maven还为全世界的Java开发者提供了一个免费的中央仓库,在其中几乎可以找到任何的流行开源软件。通过衍生工具(Nexus),我们还能对其进行快速搜索
    
        5.maven对于目录结构有要求,约定优于配置,用户在项目间切换就省去了学习成本。
    
    点赞 评论
  • qq455276333

    对比,Maven,IDE,Mark,Ant
    a.IDE:基本上所有的主流IDE都集成了Maven,我们可以在IDE中方便的运行Mave执行构建.IDE依赖大量的手工操作。编译、测试、代码生成等工作都是相互独立的,很难一键完成所有工作。手工劳动往往意味着低效,意味着容易出错很难在项目中统一所有的IDE配置,每个人都有自己的喜好。也正是由于这个原因,一个在机器A上可以成功运行的任务,到了机器B的IDE中可能就会失败。
    所以,要合理使用IDE,不过多依赖.Maven是专家.

    b.Make也许是最早的构建工具,具体不详,没用过,可以不了解.Make的强大之处在于它可以利用所有系统的本地命令,尤其是UNIX/Linux系统,丰富的功能、强大的命令能够帮助Make快速高效地完成任务。
    但是,Make将自己和操作系统绑定在一起了。也就是说,使用Make,就不能实现(至少很难)跨平台的构建,这对于Java来说是非常不友好的。此外,Makefile的语法也成问题,很多人抱怨Make构建失败的原因往往是一个难以发现的空格或Tab使用错误。

    c.Ant是意指“另一个整洁的工具”(Another Neat Tool),它最早用来构建著名的Tomcat,其作者James Duncan Davidson创作它的动机就是因为受不了Makefile的语法格式。我们可以将Ant看成是一个Java版本的Make,也正因为使用了Java,Ant是跨平台的。此外,Ant使用XML定义构建脚本,相对于Makefile来说,这也更加友好。
    和Make一样,Ant也都是过程式的,开发者显式地指定每一个目标,以及完成该目标所需要执行的任务。针对每一个项目,开发者都需要重新编写这一过程,这里其实隐含着很大的重复。Maven是声明式的,项目构建过程和过程各个阶段所需的工作都由插件实现,并且大部分插件都是现成的,开发者只需要声明项目的基本元素,Maven就执行内置的、完整的构建过程。这在很大程度上消除了重复。
    Ant是没有依赖管理的,所以很长一段时间Ant用户都不得不手工管理依赖,这是一个令人头疼的问题。幸运的是,Ant用户现在可以借助Ivy管理依赖。而对于Maven用户来说,依赖管理是理所当然的,Maven不仅内置了依赖管理,更有一个可能拥有全世界最多Java开源软件包的中央仓库,Maven用户无须进行任何配置就可以直接享用。

    3.Maven与极限编程
    极限编程(XP)是近些年在软件行业红得发紫的敏捷开发方法,它强调拥抱变化。
    首先看一下Maven如何帮助XP团队实现一些核心价值:
    ?简单。Maven暴露了一组一致、简洁的操作接口,能帮助团队成员从原来的高度自定义的、复杂的构建系统中解脱出来,使用Maven现有的成熟的、稳定的组件也能简化构建系统的复杂度。
    ?交流与反馈。与版本控制系统结合后,所有人都能执行最新的构建并快速得到反馈。此外,自动生成的项目报告也能帮助成员了解项目的状态,促进团队的交流。

    Maven几乎能够很好地支持任何软件开发方法。
    例如,在传统的瀑布模型开发中,项目依次要经历需求开发、分析、设计、编码、测试和集成发布阶段。从设计和编码阶段开始,就可以使用Maven来建立项目的构建系统。在设计阶段,也完全可以针对设计开发测试用例,然后再编写代码来满足这些测试用例。然而,有了自动化构建系统,我们可以节省很多手动的测试时间。此外,尽早地使用构建系统集成团队的代码,对项目也是百利而无一害。最后,Maven还能帮助我们快速地发布项目

    点赞 1 评论
  • u012811805
    独行侠梦 2020-04-04 12:21

    相信一提到Maven,大家脑海里浮现出来它的第一个作用,就是用来打包,但是经常“用完即走”的我们真的到了需要认认真真梳理一下Maven的相关概念了。

    Maven为我们提供了一套自动化的构建方案,从最基础的清理、编译代码、运行测试到打包和部署。这一系列过程称之为它的生命周期。

    file

    默认情况下,Maven有三套相互独立的生命周期,分别是 clean、default 和site。每个生命周期包含一些阶段(phase),阶段是有顺序的,后面的阶段依赖于前面的阶段。每个阶段的内部由 插件的 Goals(目标)组成。

    可以这样理解,其实phase就是goal的容器。真正被执行的都是goal (目标)。

    phase (阶段)被执行时,实际执行的都是被绑定到该 phase (阶段)的一系列goal(目标)。

    而 goal(目标) 与 goal (目标)之间是独立的。单独执行一个goal不会导致其他goal被执行。

    深入理解 maven 的生命周期
    maven使用一个名为 components.xml 的配置文件来描述其架构的组织结构,以我本地的maven 3.6.0版本为例。不同版本的maven, 配置文件的路径相似。

    apache-maven-${version}\lib\maven-core-${version}.jar
    \META-INFO\plexus\conponents.xml
    这里我们针对default生命周期来作详细的了解:

    file

    下图是我整理出default生命周期的所有 phase (阶段)。

    file

    mvn { 例如: mvn package }
    可以看到 当我们执行一个 简单的 mvn package 时,maven其实内部按照顺序流转了很多的phase (阶段)。

    那如何来理解 Goal (目标)呢?

    我们前面说过,一系列的 Goal (目标) 组成 了 phase (阶段)。

    相信你用过maven的很多插件吧?这里我以 打 jar包的插件为例来介绍:

    file

    聪明的你看到这个图可能已经猜到了,jar:后面的一系列单词 就是Goal (目标)。

    解释一下,goal 其实是由存在于Maven的插件plugin提供的一个个小的功能程序。你可以根据自己的实际需求,灵活的来组装他们,实现各种定制的功能。执行格式为:

    mvn [插件名称]:[goal的名称]
    再举一个实际案例,在打包时,分离出三方的依赖包。我们会使用到一个叫maven-dependency-plugin的插件。

    file

    上图表明,我制定了一个copy-dependencies 的目标,在 prepare-package 阶段执行。也就是在执行package打包之前,拷贝依赖到当前工程的lib文件夹下面。

    直接通过执行命令也能达到上述的效果:

    mvn clean dependency:copy-dependencies package
    file

    Maven 管理项目的依赖
    Maven提供的依赖管理,是其中的一大核心功能。就像文章开始所说的,我们需要一个jar包,这个jar包又依赖于另外的jar包,这种依赖关系会不断的传递,直至最后一个没有任何其他依赖包。

    Maven就是通过自动去发现和包含这些传递的依赖,避免了我们人工的去搜索下载。

    这个传递依赖的层级是没有限制的,在使用过程中需要注意的一点是,循环依赖的问题。

    file

    遭遇到循环依赖如何解决呢?Maven 提供了一个 build-helper-maven-plugin 插件。其原理是: 将三个模块合并成一个中间的工程,临时编译出模块D,然后三个模块再分别依赖D 进行编译。

    不推荐使用这种办法,这会导致我们的项目工程结构很混乱,只能作为临时规避的一个措施来使用。

    还有一种办法是通过分析依赖,从根本上消除掉循环依赖。常用的分析依赖的命令有:

    mvn dependency:help
    mvn dependency:analyze
    mvn dependency:tree
    mvn dependency:tree -Dverbose
    除了使用命令查看依赖树,常见的办法还有:

    在项目启动时把所有的加载的 jar 包都打印出来,添加 VM 参数 -verbose:class 。通过打印的信息确认是否正确的 jar 包被依赖。
    有的时候仅仅通过 mvn dependency:tree 可能无法快速的发现冲突,这个时候就可以尝试使用 Enforcer 插件,这个插件也可以自定义许多规则,我们可以使用 dependencyConvergence 规则。 来保证所有的依赖都使用相同的版本。



    org.apache.maven.plugins
    maven-enforcer-plugin
    1.3.1


    enforce




    enforce






    Maven 管理的依赖范围
    依赖范围主要是用来限制各个包的传递性。并且影响我们最终的构建结果。 在引入依赖时,通过标签来指定依赖的范围。

    file

    Maven 内部为我们提供了 6种依赖的范围:

    compile:缺省值,编译、测试都有效。
    provided:编译,测试都有效,但是在运行时并不会加入。例如Servlet API,因为Web容器本身有,如果加入就会出现冲突。

    runtime:测试、运行有效,表明这个依赖项不是编译所必须的,但是是执行时需要的。需要位于运行时的类路径中。

    test:仅测试时有效,这个范围不是可传递的。

    system:与本机相关,可移植性差。

    import:导入的依赖范围,仅适用在dependencyManager中,表示从其他pom导入dependency配置。

    dependencyManagement 作用
    上面介绍的依赖范围都比较好理解,最后一个import范围涉及到一个dependencyManagement,这里我们具体解释一下他和dependencies 的区别。

    dependencyManagement 主要有两个作用:

    一是集中管理项目的依赖项
    二是控制使用的依赖项的版本
    1、 如果有多个子模块依赖相同的包,那么放在 中来管理。

    使用 dependencyManagement 声明依赖,在项目中并不会实际引入,因此子项目需要显示声明需要用的依赖。

    当不在子项目中声明依赖的时候,是不会从父项目中继承下来的。

    只有在子项目中写了该依赖项,并且没有指定具体版本,才会从父项目中继承该项,并且 version 和 scope 都读取自父 pom

    如果子项目中指定了版本号,那么会使用子项目中指定的 jar 版本

    而对于 dependencies :

    dependencies 即使在子项目中不写该依赖项,那么子项目仍然会从父项目中继承该依赖项。父工程使用 dependencyManagement 假引用,目的是管理版本号。dependencies 用于实际上需要引入的工程,这些工程如果继承于父工程会找到对应的版本号。

    Maven 的仓库分类
    从大类来看,Maven仓库主要分为两大类,一是本地仓库,二是远程仓库。

    本地仓库,主要是用来存储从远程仓库下载的插件和 jar 包,当项目需要使用 插件 或 jar 包时,会优先从本地仓库中查找。

    远程仓库,是当无法在本地仓库中查找到包时,会默认去远程仓库下载。

    远程仓库包括了,中央仓库、镜像仓库和私服。

    file

    而在配置了多个 Maven 仓库查找依赖的顺序大致如下:

    1) 在本地仓库中寻找,如果没有则进入下一步。
    2) 在全局配置的私服仓库(settings.xml中配置的并有激活)中寻找,如果没有则进入下一步。

    3) 在项目自身配置的私服仓库(pom.xml)中寻找,如果没有则进入下一步。

    4) 在中央仓库中寻找,如果没有则终止寻找。

    点赞 1 评论
  • shen_wei
    shen_wei 2017-05-10 07:06
    点赞 评论
  • ajlgl
    岽仔玖等 2017-05-19 03:36

    管理下载包,自定义版本包下载!

    点赞 评论

相关推荐