maven模块组织管理原则

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

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

说明：

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

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

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 编写...

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

 

（3）组合

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

com.juvenxu.mvnbook.account

account-parent

1.0-SNAPSHOT

pom

import

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

 

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

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

内容：

org.slf4j

slf4j-api

${slf4j_version}

....

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

top.i5i5

maventest-common-log4j

0.0.1

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

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

 

3.插件

（1）有选择继承

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

org.apache.maven.plugins

maven-shade-plugin

1.4

 

另一个思路

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

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

 

4.屏蔽所有spring的jar

org.springframework

*

 

 

 

依赖范围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对象