而对于scope=provided的情况，则可以认为这个provided是目标容器已经provide这个artifact。换句话说，它只影响到编译，测试阶段。在编译测试阶段，我们需要这个artifact对应的jar包在classpath中，而在运行阶段，假定目标的容器（比如我们这里的liferay容器）已经提供了这个jar包，所以无需我们这个artifact对应的jar包了。
比如说，假定我们自己的项目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类，而不会出任何问题。
做一个实验就可以很容易发现，当我们用maven install生成最终的构件包ProjectABC.war后，在其下的WEB-INF/lib中，会包含我们被标注为scope=compile的构件的jar包，而不会包含我们被标注为scope=provided的构件的jar包。这也避免了此类构件当部署到目标容器后产生包依赖冲突。
Maven 使用dependencyManagement 元素来提供了一种管理依赖版本号的方式。通常会在一个组织或者项目的最顶层的父POM 中看到dependencyManagement
元素。使用pom.xml 中的dependencyManagement 元素能让
所有在子项目中引用一个依赖而不用显式的列出版本号。Maven 会沿着父子层次向上走，直到找到一个拥有dependencyManagement 元素的项目，然后它就会使用在这个dependencyManagement 元素中指定的版本号。
1 ．使用项目继承
利用项目继承可以将结构信息，部署信息，共同的依赖信息放置在单一的位置。在每个工程的 pom 中：
[...]
<parent>
<groupId>org.apache.maven.proficio</groupId>
<artifactId>proficio</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
[...]
这使得项目的 pom 可以继承顶层 pom 中的定义，检查顶层 pom 的 dependencies 部分：
<project>
[...]
<dependencies >
<dependency >
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.7</version>
<scope>test</scope>
</dependency >
</dependencies >
[...]
</project>
在各个子模块的 pom 中没有对 Junit 依赖的定义，但是从顶层 pom 中继承了依赖的定义。
为了看清楚可以在一个子模块 pom 所在目录下，执行命令
#mvn help:effective-pom
可以看到最终起效果的 pom ，这在找错时很有效。
2 ．管理依赖
在 pom 中指明 dependency management 元素的方式 maven 结合项目继承来管理依赖。在多模块应用中，可能多个子项目会有共同的依赖。此时为了正确运行，必须让所有的子项目使用依赖项的同一版本。必须确保应用的各个项目的依赖项和版本一致，才能保证测试的和发布的是相同的成果。因此，应在顶层的 pom 中定义共同的依赖关系。
在 Proficio 应用的顶层 pom 中的 dependency management 段如下：
<dependencyManagement>
<dependencies >
<dependency >
<groupId>com.devzuz.mvnbook.proficio</groupId>
<artifactId>proficio-model</artifactId>
<c>${project.version}</version>
</dependency >
<dependency >
<groupId>com.devzuz.mvnbook.proficio</groupId>
<artifactId>proficio-api</artifactId>
<version>${project.version}</version>
</dependency >
<dependency >
<groupId>com.devzuz.mvnbook.proficio</groupId>
<artifactId>proficio-core</artifactId>
<version>${project.version}</version>
</dependency >
<dependency >
<groupId>com.devzuz.mvnbook.proficio</groupId>
<artifactId>proficio-store-memory</artifactId>
<version>${project.version}</version>
</dependency >
<dependency >
<groupId>com.devzuz.mvnbook.proficio</groupId>
<artifactId>proficio-store-xstream</artifactId>
<version>${project.version}</version>
</dependency >
<dependency >
<groupId>org.codehaus.plexus</groupId>
<artifactId>plexus-container-default</artifactId>
<version>1.0-alpha-9</version>
</dependency >
</dependencies >
</dependencyManagement>
注意 ${project.version} 变量指的是应用的 version 。
顶层 pom 中的 dependencies 与 dependencyManagement 中的 dependencies 元素有一个重要的区别：
dependencyManagement 中的 dependencies 元素只表明依赖项版本的优先选择，并不影响项目的依赖项；而 dependencies 元素则影响项目的依赖项。
检查 Proficio api 模块的 pom:
<project>
<parent>
<groupId>com.devzuz.mvnbook.proficio</groupId>
<artifactId>proficio</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>proficio-api</artifactId>
<packaging>jar</packaging>
<name>Proficio API</name>
<dependencies >
<dependency >
<groupId>com.devzuz.mvnbook.proficio</groupId>
<artifactId>proficio-model</artifactId>
</dependency >
</dependencies >
</project>
其中没有指明依赖项的版本信息，在顶层 pom 中的 dependencyManagement 中表明其优选的版本是 ${project.version} 即 1.0-SNAPSHOT 。为使其模块 pom 完整，其版本信息会注入其中。
只有当 外层的dependencies 元素中没有指明版本信息时， dependencyManagement中的 dependencies 元素才起作用。
注意：一个是项目依赖，一个是多模块maven项目时候的依赖管理控制的。
