依赖管理
我们谈论继承一个dependencies因素，我们非常easy这个特性被认为是适用于accout-parent于。
子模块account-email和account-persist同一时候依赖了org.springframework:spring-core:2.5.6,spring-beans:2.5.6,spring-context:2.5.6,junit:junit:4.7。以此能够将这些公共依赖放到父模块account-parent中，两个子模块就能移除这些依赖，简化配置。
上述方法时可行的，可是有问题。
由于我们无法确定将来加入子模块就一定须要这四个模块依赖。
Maven提供dependencyManagement元素既能让子模块继承到父模块的依赖配置。又能保证子模块依赖使用的灵活性。在dependencyManagement元素下依赖声明不会引入实际的依赖。只是他能够约束dependencies下依赖的使用。
比如。能够在account-parent下加入这样的dependencyManagement配置，代码例如以下：
<modelVersion>4.0.0</modelVersion>
<groupId>com.juvenxu.mvnbook.account</groupId>
<artifactId>account-parent</artifactId>
<version>1.0.0-SNAPSHOT</version>
<packaging>pom</packaging>
<name>Account Parent</name>
<properties>
<springframework.version>2.5.6</springframework.version>
<junit.version>4.7</junit.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${springframework.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>${springframework.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>${springframework.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context-support</artifactId>
<version>${springframework.version}</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>${junit.version}</version>
<scope>test</scope>
</dependency>
</dependencies>
</dependencyManagement>如今改动account-email配置例如以下
<properties>
<javax.mail.version>1.4.1</javax.mail.version>
<greenmail.version>1.3.1b</greenmail>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${springframework.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>${springframework.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>${springframework.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context-support</artifactId>
<version>${springframework.version}</version>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>${junit.version}</version>
</dependency>
<dependency>
<groupId>javax.mail</groupId>
<artifactId>mail</artifactId>
<version>${junit.mail.version}</version>
</dependency>
<dependency>
<groupId>com.icegreen</groupId>
<artifactId>greenmail</artifactId>
<version>${greenmail.version}</version>
<scope>test</scope>
</dependency>
</dependencies>使用这样的依赖管理机制似乎不能降低太多了POM配置，可是我还是强烈推荐採用这样的方法。
原因是在于父pom中使用dependencyManagement声明依赖能够统一项目范围中依赖的版本号，降低依赖的冲突。
假设子模块中不声明依赖的使用，即使该依赖已经在父pom的dependencyManagement中声明了也不会产生不论什么实际的效果，假设account-persist:
<properties>
<dom4j.version>1.6.1</dom4j.version>
</properties>
<dependencies>
<dependency>
<groupId>dom4j</groupId>
<artifactId>dom4j</artifactId>
<version>${dom4j.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${springframework.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>${springframework.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>${springframework.version}</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>${junit.version}</version>
</dependency>
</dependencies>这里没有声明spring-context-support。那么该依赖就不会被引入。
这里顺便提一下import的依赖范围，这个依赖范围仅仅在dependencyManagement元素下才有效果。使用该范围的依赖通常指向一个POM，作用是将目标POM中的dependencyManagement配置导入并合并到当前pom的dependencyManagement元素中。比如：
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.juvenxu.mvnbook.account</groupId>
<artifactId>account-parent</artifactId>
<version>1.0-SNAPSHOT</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>插件管理
Maven提供了dependencyManagement元素帮助管理依赖，相似的Maven也提供了pluginManagement元素帮助管理插件。在该元素中配置的依赖不会造成实际的插件调用行为，当POM中配置了真正了plugin元素，而且其groupId和artifactId与pluginManagement中配置的插件匹配时。pluginManagement的配置才会影响到实际的插件行为
比如：
<bulid>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.1.1</version>
<executions>
<execution>
<id>attach-sources</id>
<phase>verify</phase>
<goals>
<goal>jar-no-fork</goal>
</goals>
<execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</bulid>将其jar-no-fork目标绑定到了verity生命周期阶段，以生成项目源代码包，当子模块须要生成源代码包的时候，仅仅须要例如以下简单的配置。代码例如以下：
<bulid>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<plugin>
</plugins>
</build>假设子模块须要不同于父模块的插件配置，能够自行配置以覆盖父模块的pluginManagement配置。有了pluginManagement元素，account-email和account-persist的pom也得以简化。
他们都配置了maven-compiler-plugin和maven-resoureces-plugin。能够将这两个插件配置移到account-parent的pluginManagement元素中。
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<configuration>
<encoding>UTF-8</encoding>
</configuration>
</plugins>
</pluginManagement>
</build>account-email和accoun-persist能够全然移除关于maven-compiler-plugin和maven-resources-plugin的配置，但他们仍能享受这两个插件服务。
当项目的多个模块有相同的插件配置时，应当将配置移到父pom的pluginManagement的元素中。
即使各个模块对同一个插件的详细配置不尽相同，也应当使用父pom的pluginManagement元素统一声明插件的版本号。甚至能够要求将全部用到的插件的版本号在父pom的pluginManagement元素中声明，子模块使用插件时不配置版本号信息。这么做能够统一项目的插件版本号，避免潜在的插件不一致或者不稳定问题。也更易于维护。