maven中DependencyManagement和Dependencies

上次这边朋友问我一个问题,就是他们在pom.xml中的dependency中,看到有一些是provided的情况,比如如下:

双击代码全选
1
2
3
4
5
6
    com.liferay.portal
    portal-impl
    6.1 . 0
    provided

他们问我scope在何种情况下要设置为provided,以及和scope设置为compile的区别。

解释:

其实这个问题很简单。

对于scope=compile的情况(默认scope),也就是说这个项目在编译,测试,运行阶段都需要这个artifact对应的jar包在classpath中。

而对于scope=provided的情况,则可以认为这个provided是目标容器已经provide这个artifact。换句话说,它只影响到编译,测试阶段。在编译测试阶段,我们需要这个artifact对应的jar包在classpath中,而在运行阶段,假定目标的容器(比如我们这里的liferay容器)已经提供了这个jar包,所以无需我们这个artifact对应的jar包了。

听起来很玄乎,对吧,其实一点也不难理解。举个scope=provided的例子。

比如说,假定我们自己的项目ProjectABC 中有一个类叫C1,而这个C1中会import这个portal-impl的artifact中的类B1,那么在编译阶段,我们肯定需要这个B1,否则C1通不过编译,因为我们的scope设置为provided了,所以编译阶段起作用,所以C1正确的通过了编译。测试阶段类似,故忽略。

那么最后我们要吧ProjectABC部署到Liferay服务器上了,这时候,我们到$liferay-tomcat-homewebappsROOTWEB-INFlib下发现,里面已经有了一个portal-impl.jar了,换句话说,容器已经提供了这个artifact对应的jar,所以,我们在运行阶段,这个C1类直接可以用容器提供的portal-impl.jar中的B1类,而不会出任何问题。

实际插件的行为:

刚才我们讲述的是理论部分,现在我们看下,实际插件在运行时候,是如何来区别对待scope=compile和scope=provided的情况的。

做一个实验就可以很容易发现,当我们用maven install生成最终的构件包ProjectABC.war后,在其下的WEB-INF/lib中,会包含我们被标注为scope=compile的构件的jar包,而不会包含我们被标注为scope=provided的构件的jar包。这也避免了此类构件当部署到目标容器后产生包依赖冲突。




Maven中节点和节点的区别  





解释如下:

Maven 使用dependencyManagement 元素来提供了一种管理依赖版本号的方式。通常会在一个组织或者项目的最顶层的父POM 中看到dependencyManagement 元素。使用pom.xml 中的dependencyManagement 元素能让
所有在子项目中引用一个依赖而不用显式的列出版本号。Maven 会沿着父子层次向上走,直到找到一个拥有dependencyManagement 元素的项目,然后它就会使用在这个dependencyManagement 元素中指定的版本号。

1 .使用项目继承

利用项目继承可以将结构信息,部署信息,共同的依赖信息放置在单一的位置。在每个工程的 pom 中:

[...]

org.apache.maven.proficio

proficio

1.0-SNAPSHOT

[...]

这使得项目的 pom 可以继承顶层 pom 中的定义,检查顶层 pom 的 dependencies 部分:

[...]

junit

junit

4.7

test

[...]

在各个子模块的 pom 中没有对 Junit 依赖的定义,但是从顶层 pom 中继承了依赖的定义。

为了看清楚可以在一个子模块 pom 所在目录下,执行命令

#mvn help:effective-pom

可以看到最终起效果的 pom ,这在找错时很有效。

2 .管理依赖

在 pom 中指明 dependency management 元素的方式 maven 结合项目继承来管理依赖。在多模块应用中,可能多个子项目会有共同的依赖。此时为了正确运行,必须让所有的子项目使用依赖项的同一版本。必须确保应用的各个项目的依赖项和版本一致,才能保证测试的和发布的是相同的成果。因此,应在顶层的 pom 中定义共同的依赖关系。

在 Proficio 应用的顶层 pom 中的 dependency management 段如下:

  

    

      

        com.devzuz.mvnbook.proficio

        proficio-model

        ${project.version}

      

      

        com.devzuz.mvnbook.proficio

        proficio-api

        ${project.version}

      

      

        com.devzuz.mvnbook.proficio

        proficio-core

         ${project.version}

      

      

        com.devzuz.mvnbook.proficio

        proficio-store-memory

        ${project.version}

      

      

        com.devzuz.mvnbook.proficio

        proficio-store-xstream

        ${project.version}

      

      

        org.codehaus.plexus

        plexus-container-default

        1.0-alpha-9

      

    

  

注意 ${project.version} 变量指的是应用的 version 。

顶层 pom 中的 dependencies 与 dependencyManagement 中的 dependencies 元素有一个重要的区别:

dependencyManagement 中的 dependencies 元素只表明依赖项版本的优先选择,并不影响项目的依赖项;而 dependencies 元素则影响项目的依赖项。

检查 Proficio api 模块的 pom:

  

    com.devzuz.mvnbook.proficio

    proficio

    1.0-SNAPSHOT

  

  4.0.0

  proficio-api

  jar

  Proficio API

  

    

      com.devzuz.mvnbook.proficio

       proficio-model

    

  

其中没有指明依赖项的版本信息,在顶层 pom 中的 dependencyManagement 中表明其优选的版本是 ${project.version} 即 1.0-SNAPSHOT 。为使其模块 pom 完整,其版本信息会注入其中。

只有当 外层的dependencies 元素中没有指明版本信息时, dependencyManagement中的 dependencies 元素才起作用。

注意:一个是项目依赖,一个是多模块maven项目时候的依赖管理控制的。


你可能感兴趣的:(maven)