maven模块组织管理原则

1.根据面向接口编程原则，一个功能模块分为：api和service 2个模块。service模块依赖api模块，那么service的依赖的其他第三方包也要通过api引入嘛？需要遵循什么原则？

谁使用谁添加依赖原则 + 尽量少的显示依赖(重视利用传递性依赖)+利用依赖范围

说明：

A项目中使用了B.jar，A就需要添加依赖jar；版本号统一交给父pom控制；

A项目利用传递性依赖，已经将B.jar引入，则不用显示的编写<dependencies>

A项目在显示依赖B.jar时，需要明确给出依赖范围，尽量少提供不必要的依赖。

依赖范围Scope	对于compile classpath有效	对于test classpath有效	对于runtime classpath有效	例子
compile	y	y	y	spring-core
test		y		JUnit
runtime		y	y	JDBC驱动实现
provided	y	y		servlet-api
system	y	y

 

2.继承与聚合

pom文件可以继承和聚合

（1）继承

可继承的pom元素如下：

groupId：项目组ID

version：项目版本

description：项目描述

organization：项目的组织信息

inceptionYear：项目的创建年份

url：项目的url地址

developers：项目的开发者信息

contributors：项目贡献值信息

distributionManagement：项目的部署配置

issueManagement：项目的缺陷跟踪系统信息

ciManagement：项目持续集成系统信息

scm：项目的版本控制系统消息

mailingLists：项目的邮件列表信息

properties：自定义的maven属性

dependencies：项目的依赖配置

dependencyManagement：项目的依赖管理配置

repositories：项目的仓库配置

build：项目的源码目录配置，输出目录配置，插件配置，插件管理配置等

reporting：项目的报告输出目录配置等

（2）有选择继承

父pom 编写<dependencyManagement>...</dependencyManagement>

子pom 可以有选择继承<dependencyManagement>中的jar

 

（3）组合

1.需要用到<dependencyManagement>时，可以导入其他项目积累的pom，如：

<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>

将account-parent pom中的<dependencyManagement>,为自己项目使用。达到重用目的。这种方式就把jar的版本控制权交给了account-parent pom 文件。

 

2.导入集合pom。开发者可以提供公共的集合pom。例如:

maventest-common-log4j-pom 文件,其中是关于log4j相关依赖包集合。

内容：

<dependencies>

<dependency>

<groupId>org.slf4j</groupId>

<artifactId>slf4j-api</artifactId>

<version>${slf4j_version}</version>

</dependency>

....

</dependencies>

项目A 导入 maventest-common-log4j-pom 文件，项目A也就引入了log4j的一系列包。

<dependencies>

<!--导入 pom 文件, 而非引入jar-->

<dependency>

<groupId>top.i5i5</groupId>

<artifactId>maventest-common-log4j</artifactId>

<version>0.0.1</version>

</dependency>

</dependencies>

优势：省去了繁重的jar依赖管理；把常用的第三jar整理成不同的集合pom，可以重复利用；

缺点：依赖jar的版本不受A项目控制。只能等待集合pom的提供者升级

 

3.插件

（1）有选择继承

（2）将所有模块统一打包出去。使用maven-shade-plugin插件。

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-shade-plugin</artifactId>

<version>1.4</version>

 

另一个思路

项目A依赖项目B(其他部门项目)，项目C同样依赖项目B；项目D同样依赖项目B；

思路：项目A封装对项目B接口。项目C，项目D依赖项目A，由项目A统一控制对外依赖。

 

4.屏蔽所有spring的jar

<exclusions>

<exclusion>

<groupId>org.springframework</groupId>

<artifactId>*</artifactId>

</exclusion>

</exclusions>

 

 

 

依赖范围Scope	对于compile classpath有效	对于test classpath有效	对于runtime classpath有效	例子
compile	y	y	y	spring-core
test		y		JUnit
runtime		y	y	JDBC驱动实现
provided	y	y		servlet-api
system	y	y

项目dao层 和 pojo（enity）层 从api模块独立成2个模块

新模式：

1.x-dao 从service中独立出来，单独负责数据库相关信息，包括：数据库联系信息，dao层，service模块直接引入jar包即可。如果service需要自己指定数据库，则只需要再classpath中编辑jdbc.properts文件即可，x-dao在家中文件时会优先价值service模块中的配置文件；做到了dao层和service层的解耦；

2.pojo 从api模块中独立；使api只专注于服务接口，不依赖数据库映射对象的接口。避免第三方使用api接口时，引入不关心的jar；

3.x-pojo 对象，最好不要依赖mybaits的注解。而时采用xml的形式，使用mybatis

4.x-api 完全可以不依赖x-pojo模块，自己实现接口的入参，出参对象，即VO对象