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