maven配置多模块项目pommodules--688IT编程网

maven配置多模块项⽬pommodules

所有⽤Maven管理的真实的项⽬都应该是分模块的，每个模块都对应着⼀个l。它们之间通过继承和聚合（也称作多模块，multi-module）相互关联。那么，为什么要这么做呢？我们明明在开发⼀个项⽬，划分模块后，导⼊Eclipse变成了N个项⽬，这会带来复杂度，给开发带来不便。

为了解释原因，假设有这样⼀个项⽬，很常见的Web应⽤。在这个应⽤中，我们分了⼏层：

Dao层负责数据库交互，封装了Hibernate交互的类。

Service层处理业务逻辑，放⼀些Service接⼝和实现相关的Bean。

Web层负责与客户端交互，主要有⼀些Structs的Action类。

对应的，在⼀个项⽬中，我们会看到⼀些包名：

这样整个项⽬的框架就清晰了，但随着项⽬的进⾏，你可能会遇到如下问题：

1. 这个应⽤可能需要有⼀个前台和⼀个后台管理端（web或者swing），你发现⼤部分dao，⼀些service，和⼤部分util是在两个应⽤中

可。这样的问题，你⼀周内遇到了好⼏次。

2. l中的依赖列表越来越长以重⽤的，但是，由于⽬前只有⼀个项⽬（WAR），你不得不新建⼀个项⽬依赖这个WAR，这变得⾮

常的恶⼼，因为在Maven中配置对WAR的依赖远不如依赖JAR那样简单明了，⽽且你根本不需要app.web。有⼈修改了dao，提交到svn并且不⼩⼼导致build失败了，你在编写service的代码，发现编译不过，只能等那⼈把dao修复了，你才能继续进⾏，很多⼈都在修改，到后来你根本就不清楚哪个依赖是谁需要的，渐渐的，很多不必要的依赖被引⼊。甚⾄出现了⼀个依赖有多个版本存在。

3. build整个项⽬的时间越来越长，尽管你只是⼀直在web层⼯作，但你不得不build整个项⽬。

4. 某个模块，⽐如util，你只想让⼀些经验丰富的⼈来维护，可是，现在这种情况，每个开发者都能修改，这导致关键模块的代码质量不

能达到你的要求。

我们会发现，其实这⾥实际上没有遵守⼀个设计模式原则：“⾼内聚，低耦合”。虽然我们通过包名划分了层次，并且你还会说，这些包的依赖都是单向的，没有包的环依赖。这很好，但还不够，因为就构建层次来说，所有东西都被耦合在⼀起了。因此我们需要使⽤Maven划分模块。

⼀个简单的Maven模块结构是这样的：

---- app-parent

|-- l (pom)

|-- app-util

| |-- l (jar)

|-- app-dao

| |-- l (jar)

|-- app-service

| |-- l (jar)

|-- app-web

|-- l (war)

上述简单⽰意图中，有⼀个⽗项⽬(app-parent)聚合很多⼦项⽬（app-util, app-dao, app-service, app-web）。每个项⽬，不管是⽗⼦，都含有⼀个l⽂件。⽽且要注意的是，⼩括号中标出了每个项⽬的打包类型。⽗项⽬是pom，也只能是pom。⼦项⽬有jar，或者war。根据它包含的内容具体考虑。

这些模块的依赖关系如下：

app-dao --> app-util

app-service --> app-dao

app-web --> app-service

注意依赖的传递性（⼤部分情况是传递的，除⾮你配置了特殊的依赖scope），app-dao依赖于app-util，app-service依赖于app-dao，于是app-service也依赖于app-util。同理，app-web依赖于app-dao,app-util。

⽤项⽬层次的划分替代包层次的划分能给我们带来如下好处：

1. ⽅便重⽤，如果你有⼀个新的swing项⽬需要⽤到app-dao和app-service，添加对它们的依赖即可，你不再需要去依赖⼀个WAR。⽽

有些模块，如app-util，完全可以渐渐进化成公司的⼀份基础⼯具类库，供所有项⽬使⽤。这是模块化最重要的⼀个⽬的。

2. 由于你现在划分了模块，每个模块的配置都在各⾃的l⾥，不⽤再到⼀个混乱的纷繁复杂的总的POM中寻⾃⼰的配置。

3. 如果你只是在app-dao上⼯作，你不再需要build整个项⽬，只要在app-dao⽬录运⾏mvn命令进⾏build即可，这样可以节省时间，尤其

是当项⽬越来越复杂，build越来越耗时后。

4. 某些模块，如app-util被所有⼈依赖，但你不想给所有⼈修改，现在你完全可以从这个项⽬结构出来，做成另外⼀个项⽬，svn只给特

定的⼈访问，但仍提供jar给别⼈使⽤。

5. 多模块的Maven项⽬结构⽀持⼀些Maven的更有趣的特性（如DepencencyManagement），这留作以后讨论。

接下来讨论⼀下POM配置细节，实际上⾮常简单，先看app-parent的l：

1. <project xmlns="/POM/4.0.0" xmlns:xsi="/2001/XMLSchema-instance"

2. xsi:schemaLocation="/POM/4.0.0 /maven-v4_0_0.xsd">

3. <modelVersion>

4.0.0</modelVersion>

4. <groupId&myapp</groupId>

5. <artifactId>app-parent</artifactId>

6. <packaging>pom</packaging>

7. <version>1.0-SNAPSHOT</version>

8. <modules>

9. <module>app-util</module>

10. <module>app-dao</module>

11. <module>app-service</module>

12. <module>app-web</module>

13. </modules>

14. </project>

Maven的坐标GAV（groupId, artifactId, version）在这⾥进⾏配置，这些都是必须的。特殊的地⽅在于，这⾥的packaging为pom。所有带有⼦模块的项⽬的packaging都为pom。packaging如果不进⾏配置，它的默认值是jar，代表Maven会将项⽬打成⼀个jar包。

该配置重要的地⽅在于modules，例⼦中包含的⼦模块有app-util, app-dao, app-service, app-war。在Maven build app-parent的时候，它会根据⼦模块的相互依赖关系整理⼀个build顺序，然后依次build。

这就是⼀个⽗模块⼤概需要的配置，接下来看⼀下⼦模块符合配置继承⽗模块。、

1. <project xmlns="/POM/4.0.0" xmlns:xsi="/2001/XMLSchema-instance"

2. xsi:schemaLocation="/POM/4.0.0 /maven-v4_0_0.xsd">

3. <parent>

4. <artifactId>app-parent</artifactId>

5. <groupId&myapp</groupId>

6. <version>1.0-SNAPSHOT</version>

7. </parent>

8. <modelVersion>4.0.0</modelVersion>

9. <artifactId>app-util</artifactId>

10. <dependencies>

11. <dependency>

12. <groupId>commons-lang</groupId>

13. <artifactId>commons-lang</artifactId>

14. <version>2.4</version>

15. </dependency>

16. </dependencies>

17. </project>

app-util模块继承了app-parent⽗模块，因此这个POM的⼀开始就声明了对app-parent的引⽤，该引⽤是通过Maven坐标GAV实现的。⽽关于项⽬app-util本⾝，它却没有声明完整GAV，这⾥我们只看到了artifactId。这个POM并没有错，groupId和version默认从⽗模块继承了。实际上⼦模块从⽗模块继承⼀切东西，包括依赖，插件配置等等。

此外app-util配置了⼀个对于commons-lang的简单依赖，这是最简单的依赖配置形式。⼤部分情况，也是通过GAV引⽤的。

再看⼀下app-dao，它也是继承于app-parent，同时依赖于app-util：

1. <project xmlns="/POM/4.0.0" xmlns:xsi="/2001/XMLSchema-instance"

2. xsi:schemaLocation="/POM/4.0.0 /maven-v4_0_0.xsd">

3. <parent>

4. <artifactId>app-parent</artifactId>

5. <groupId&myapp</groupId>

6. <version>1.0-SNAPSHOT</version>

7. </parent>

8. <modelVersion>4.0.0</modelVersion>

9. <artifactId>app-dao</artifactId>

10. <dependencies>

11. <dependency>

12. <groupId&myapp</groupId>

13. <artifactId>app-util</artifactId>

14. <version>${project.version}</version>

15. </dependency>

16. </dependencies>

17. </project>

该配置和app-util的配置⼏乎没什么差别，不同的地⽅在于，依赖变化了，app-dao依赖于app-util。这⾥要注意的是version的值为${project.version}，这个值是⼀个属性引⽤，指向了POM的project/version的值，也就是这个POM对应的version。由于app-dao的version继承于app-parent，因此它的值就是1.0-SNAPSHOT。⽽app-util也继承了这个值，因此在所有这些项⽬中，我们做到了保持版本⼀致。

这⾥还需要注意的是，app-dao依赖于app-util，⽽app-util⼜依赖于commons-lang，根据传递性，app-dao也拥有了对于commons-lang的依赖。

app-service我们跳过不谈，它依赖于app-dao。我们最后看⼀下app-web：

1. <project xmlns="/POM/4.0.0" xmlns:xsi="/2001/XMLSchema-instance"

2. xsi:schemaLocation="/POM/4.0.0 /maven-v4_0_0.xsd">

3. <parent>

4. <artifactId>app-parent</artifactId>

5. <groupId&myapp</groupId>

6. <version>1.0-SNAPSHOT</version>

7. </parent>

8. <modelVersion>4.0.0</modelVersion>

9. <artifactId>app-web</artifactId>

10. <packaging>war</packaging>

11. <dependencies>

12. <dependency>

13. <groupId&myapp</groupId>

14. <artifactId>app-service</artifactId>

15. <version>${project.version}</version>

16. </dependency>

17. </dependencies>

18. </project>

app-web依赖于app-service，因此配置了对其的依赖。

由于app-web是我们最终要部署的应⽤，因此它的packaging是war。为此，你需要有⼀个⽬录src/main/webapp。并在这个⽬录下拥有web 应⽤需要的⽂件，如/l。没有l，Maven会报告build失败，此外你可能还会有这样⼀些⼦⽬录：/js, /img, /css ... 。

看看Maven是如何build整个项⽬的，我们在 app-parent 根⽬录中运⾏ mvn clean install ，输出的末尾会有⼤致这样的内容：

...

[INFO] [war:war]

[INFO] Packaging webapp

[INFO] Assembling webapp[app-web] in [/home/juven/workspaces/ws-others/myapp/app-web/target/app-web-1.0-SNAPSHOT] [INFO] Processing war project

[INFO] Webapp assembled in[50 msecs]

[INFO] Building war: /home/juven/workspaces/ws-others/myapp/app-web/target/app-web-1.0-SNAPSHOT.war

[INFO] [install:install]

[INFO] Installing /home/juven/workspaces/ws-others/myapp/app-web/target/app-web-1.0-SNAPSHOT.war to

/home/juven/.m2/repository/org/myorg/myapp/app-web/1.0-SNAPSHOT/app-web-1.0-SNAPSHOT.war

[INFO]