以多模块的形式组织项目，乃是maven一直提倡的方式。如果使用得当，多模块可以可以帮助项目划分模块，鼓励重用，防止POM变得过于庞大，方便某个模块的构建，而不用每次都构建整个项目，并且使得针对某个模块的特殊控制更为方便（关于多模块优势的描述可以参见juvenshun的博文Maven最佳实践：划分模块http://juvenshun.iteye.com/blog/305865。）

 

虽然多模块能给项目带来诸多好处，单实际操作时常常遇到一些各种各样的增加项目复杂度的问题，导致开发的效率下降。这里总结了一些在多模块项目实践中的常见的问题和解决办法，帮助降低复杂度，减少程序员的无谓劳动。

 

  • 组织依赖

在多模块项目中，不同的模块依赖的包各自不同，而这些依赖中又往往会有一些相同的依赖。一种常见的组织方式是，每个程序员在自己负责的子模块的pom文件中加入该模块需要的依赖，然后往下进行开发。这样做会出现项目对同一个类库依赖各种不同的版本的情况，给项目带来了复杂度，同时也容易出现各种各样的问题。

 

最佳实践应该是，将可能被多个项目共同依赖的的包以及maven插件设置放在父模块的pom文件中，以dependencyManagement和pluginManagement的形式进行管理。这样做，一来实现了依赖的统一管理，二来统一了项目对类库依赖的版本，减少对程序员该来的迷惑和思考。

 

  • 子模块间依赖

对于项目子模块间依赖，可以选择放到dependencyManagement中，也可以放在各自子模块的pom文件中，但需要注意的一点是，每个子模块的版本最好和整个项目的版本统一，通过在父模块pom的properties配置中设置project.version属性，各子模块依赖版本均以此为准的方式来处理。否则子模块的升级会带来各种意想不到的情况。

 

  • 版本控制

Web项目中常用到spring框架，该框架的依赖可分为spring-core，spring-beans等等若干个，它们的版本号往往是统一的。如果我们因为某些原因需要改变spring的版本，需要将所有依赖的版本都进行修改，这样显然不是明智的做法。减少重复劳动的方法是，将重复存在的版本抽取出来，统一放在父模块pom的properties配置中统一管理。当日后需要变更版本时，只需要对父模块pom进行修改，便可到处生效。

 

另一个更进一步的做法是，新建一个子模块spring-dep，设置打包方式为pom，将spring相关的依赖全部放到这个子模块中，当项目需要使用spring时，只需要添加对该模块的依赖即可。这样做的好处是，spring-dep模块不仅可以在当前项目中使用，还可以放到其他的项目中，一劳永逸的解决了spring的版本问题。以此类推，也可以用这种方式对测试等等较为通用的框架依赖进行管理。

 

  • 排除单个包依赖

在使用日志系统时，如果使用到了slf4j框架，则在依赖中需要将comons-logging依赖排除，避免其和JCL-over-SLF4J发生冲突，导致不能正常打日志。为了解决这个问题，在maven仓库中对commons-logging存在99.0-does-not-exist这个版本，该版本其实空无一物，因此依赖该版本相当于什么都没有依赖。当需要排除这个依赖时，则在父模块的pom中依赖commons-logging，并将版本设为99.0-does-not-exist，即可排除该依赖。

 

这是一个较为特别的排除依赖的方法，那么，除此之外还有没有更通用一些的手段呢？答案是有的，在父模块的pom文件的dependency中设置对要排除的包的依赖，然后将其scope设置为provided，根据依赖传递性，所有子模块中对该包的依赖都以父模块pom中的定义为准，所以最终依赖将不会包含该包，也就达到了排除依赖的目的。

 

这样做虽然能够排除依赖，不过需要注意的一点是，在单元测试过程中，该依赖仍然存在，会对单元测试造成影响。

 

  • 多个spring子模块

在开发web项目时，通常会将项目分为project-web，project-service，project-dao等等若干个子模块。这时，可能需要在多个子模块中使用到spring框架的IoC机制，定义一些特定功能的bean。那我们如何在web子模块中识别并获取到其他子模块（比如service）的bean呢？首先，我们从部署的角度来看，无论是单模块项目，或者是多模块项目，在项目编译完成后，通常会被整体打包到一个war包中，然后将其部署到Web容器中运行，容器通过唯一的web.xml文件作为web工程配置的入口，执行这个web项目。因此，我们在需要使用spring框架的模块中配置好相应的applicationContext.xml文件（要放到src/main/resources下，这样能通过classpath轻松的找到），然后在web子模块的web.xml文件中引用这些所有的applicationContext文件。这样一来，所有的bean都能在web子模块中被识别和调用。

 

如果使用spring注解来注入类，那么一个比较好的实践是，对所有子模块的包命名相同的前缀（比如com.company.product.*)，然后在web子模块的applicationContext文件中使用<context:component-scan base-package="com.company.product.*"/>，这里就能够扫描到所有com.company.product.*包下的component/controller/service，不用再在各个子模块中定义applicationContext文件。

 

  • 使用maven filter过滤WEB-INF目录下文件

Maven filter能够过滤资源（resource）文件，通过在pom文件中配置：


<filters>
    <filter>src/main/resources/config.properties</filter>
</filters>
<resources>
    <resource>
        <directory>src/main/resources</directory>
        <filtering>true</filtering>
    </resource>
</resources>



根据 properties 文件替换资源文件中的占位符。

而当需要过滤src/main/webapp/WEB-INF/目录下的文件（比如web.xml）时，不能在这里配置，因为这里是处理资源文件的，最终这些资源文件都会被放到target/classes目录下，不能满足需求，因此需要再另外做配置：

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-war-plugin</artifactId>
    <configuration>
        <webResources>
            <webResource>
                <!-- 过滤的目录-->
                <directory>${basedir}/src/main/webapp/WEB-INF</directory>
                <includes>
                    <!-- 添加需要过滤的文件 ，支持通配符-->
                    <include>web.xml</include>
                </includes>
                <!-- 打包之后目标目录 -->
                <targetPath>WEB-INF</targetPath>
                    <filtering>true</filtering>
            </webResource>
        </webResources>
    </configuration>
</plugin>