多模块项目的POM重构

在本专栏的上一篇文章POM重构之增还是删中，我们讨论了一些简单实用的POM重构技巧，包括重构的前提——持续集成，以及如何通过添加或者删除内容来提高POM的可读性和构建的稳定性。但在实际的项目中，这些技巧还是不够的，特别值得一提的是，实际的Maven项目基本都是多模块的，如果仅仅重构单个POM而不考虑模块之间的关系，那就会造成无谓的重复。本文就讨论一些基于多模块的POM重构技巧。 

重复，还是重复 

程序员应该有狗一般的嗅觉，要能嗅到重复这一最常见的坏味道，不管重复披着怎样的外衣，一旦发现，都应该毫不留情地彻底地将其干掉。不要因为POM不是产品代码而纵容重复在这里发酵，例如这样一段代码就有重复： 

<dependency> 
  <groupId>org.springframework</groupId> 
  <artifactid>spring-beans</artifactId> 
  <version>2.5</version> 
</dependency> 
<dependency> 
  <groupId>org.springframework</groupId> 
  <artifactid>spring-context</artifactId> 
  <version>2.5</version> 
</dependency> 
<dependency> 
  <groupId>org.springframework</groupId> 
  <artifactid>spring-core</artifactId> 
  <version>2.5</version> 
</dependency> 
你会在一个项目中使用不同版本的SpringFramework组件么？答案显然是不会。因此这里就没必要重复写三次<version>2.5</version>，使用Maven属性将2.5提取出来如下： 

<properties> 
  <spring.version>2.5</spring.version> 
</properties> 
<depencencies> 
  <dependency> 
    <groupId>org.springframework</groupId> 
    <artifactid>spring-beans</artifactId> 
    <version>${spring.version}</version> 
  </dependency> 
  <dependency> 
    <groupId>org.springframework</groupId> 
    <artifactid>spring-context</artifactId> 
    <version>${spring.version}</version> 
  </dependency>