Maven多模块管理
为什么需要使用Maven的多模块管理模式
随着项目的不断发展,需求的不断细化与添加,代码越来越多,结构也越来越复杂,这时候就会遇到各种问题
- 不同方面的代码之间相互耦合,这时候一系统出现问题很难定位到问题的出现原因,即
- 使定位到问题也很难修正问题,可能在修正问题的时候引入更多的问题。
- 多方面的代码集中在一个整体结构中,新入的开发者很难对整体项目有直观的感受,增加了新手介入开发的成本,需要有一个熟悉整个项目的开发者维护整个项目的结构(通常在项目较大且开发时间较长时这是很难做到的)。
- 开发者对自己或者他人负责的代码边界很模糊,这是复杂项目中最容易遇到的,导致的结果就是开发者很容易修改了他人负责的代码且代码负责人还不知道,责任追踪很麻烦。
- 版本兼容问题等
- …
将一个复杂项目拆分成多个模块是解决上述问题的一个重要方法。 拆分的好处
- 多模块的划分可以降低代码之间的耦合性(从类级别的耦合提升到jar包级别的耦合)
- 每个模块都可以是自解释的(通过模块名或者模块文档)
- 模块还规范了代码边界的划分,开发者很容易通过模块确定自己所负责的内容
- …
按职责划分
module-test-service
module-test-dao
module-test-controller
module-test-util
…
按功能划分
–module-test-common公共部分
–module-test-order订单
–module-test-checkout购物车
–module-test-pay支付
–module-test-catory类目
–module-test-product商品
–module-test-price价格
–…
搭建多模块项目
我使用的的idea19.3版本,版本不一样会再创建项目时出现一些差别。
1、创建maven项目
java/web项目都行
2、成为父模块的要求
1、删除掉工程的下src目录,(所以才是创建Java/web项目都一样)
2、将pom文件中的packaging标签文本内容设置为pom(我发现packaging标签就算不设置,最后也会自动添加上)
3、创建子模块
项目构建和普通项目一样,注意在这个位置停下,选择父工程的pom之后的变化
这里有几个位置要注意下。
1、选择父工程的项目一定要删除src,否则不会成功
2、GroupId,选中pom文件后会自动设置为父工程的GroupId,在19版本前好像是不能够修改的 但是我的19.3能够修改的
以自己使用的版本为标准吧
3、Vsersion,和GruopId同样
构建完成观察父工程pom文件的变化
在前面我并没有设置packaging为pom,但是packageing标签自动添加了
多出 标签,指定了包含的所有子工程
<modules>
<module>../002-maven-son</module>
</modules>
观察子工程pom文件
多出了标签,指定了父工程的GAV坐标 并且使用标签指向父工程的pom文件位置
…是因为当前的子工程和父工程在相对路径下
并且子工程的GAV坐标只出现了一个,没有GruopId,Version标签是因为在创建子工程项目时,默认选择使用了父工程的GruopId 以及 Version
子模块之间的依赖
使用maven的多模块模式就是为了管理依赖,统一依赖版本号,子工程会无条件继承父工程定义好的依赖。
但这种方法会造成依赖的冗余,当某个工程不需要某个依赖 但他依然会继承被父工程定义好的依赖,所以使用标签加强管理依赖,
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>5.2.5.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>5.2.5.RELEASE</version>
</dependency>
</dependencies>
</dependencyManagement>
子工程pom依赖使用就需要指定依赖坐标,但是不需要指定版本号,因为版本号在父工程中已经被定义好了。
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<!--也可以在子工程中重新声明需要使用的版本号,会覆盖掉父工程中指定的版本号-->
<!--<version>5.2.5.RELEASE</version>-->
</dependency>
</dependencies>
缺陷:当父工程需要非常多的依赖时,管理起来也是非常麻烦的,所以使用中定义好版本号,在位置使用${xxx} 引用
一般是 artifactId标签内容 + version = ${spring-webmvc-version}
这样只需要在properties标签中找到需要更改的依赖版本号,依赖得版本就会改变。
<properties>
<spring-context-version>5.2.5.RELEASE</spring-context-version>
<spring-webmvc-version>5.2.5.RELEASE</spring-webmvc-version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>${spring-context-version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>${spring-webmvc-version}</version>
</dependency>
</dependencies>
</dependencyManagement>
个人认为:父工程的pom本质上就是统一管理依赖的版本号。