上一篇咱们讲解了 Gradle 构建项目的生命周期,这一篇咱们来看下 Gradle 的另一个重要的知识点,就是依赖管理,那为什么需要依赖管理呢?
几乎所有基于 JVM 的软件项目都需要依赖外部的类库来重用现有的功能代码.自动化依赖管理可以明确依赖的版本,能解决传递性依赖带来的版本冲突问题.
而Gradle 就满足这两个条件,以下就来看下依赖管理的关键点.
dependencies {
testCompile group: 'junit', name: 'junit', version: '4.12'
// 简写
// testCompile 'junit:junit:4.12'
}
在 dependencies 中指明依赖的 jar 包
repositories {
// 配置本地仓库
mvaenLocal()
// 配置中央仓库
// jcenter()
mavenCentral()
// 自定义私服地址
maven {
url ''
}
}
在 repositories 中配置仓库的指向,在这里面可配置多个仓库,会按配置的顺序去查找jar包,找到则获取,找不到继续到下一个配置的仓库去查找.一般是在最前面配置公司的私服,使用自定义仓库方式配置.
比如: A 依赖 B,如果 C 依赖 A,那么 C 依赖 B
就是因为依赖的传递性,所以才会出现版本的冲突问题.以下通过一张图来了解下Gradle 的自动化依赖管理流程.
由图可得知,Gradle 工具从远程仓库下载 jar 包到本地仓库,Gradle 工具需要依赖配置文件,如果同一个 jar 经常使用会被存入到依赖缓存中.
在 build.gradle 中的 dependencies 中配置依赖,依赖分以下四种依赖.
源码依赖: compile , runtime
测试依赖: testCompile, runtime
以上的四种配置选用的主要判断依据是是否仅是运行阶段需要依赖或是否仅是测试阶段需要依赖
.
仅运行阶段需要依赖使用 runtime ,如果仅是测试阶段需要依赖加 test 前缀 testCompile 或 testRuntime.
以上是依赖管理的配置和概念点的讲解,接下来咱们来实际配置一个依赖,来为项目加入一个logbok依赖.
5.1 到中央仓库查找 logbok 的配置
http://mvnrepository.com/search?q=logback
5.2 拷贝配置到 build.gradle 中配置依赖
dependencies {
testCompile 'junit:junit:4.12'
testCompile 'ch.qos.logback:logback-classic:1.2.3'
}
5.3 刷新导入
在 test 包下书写 MyTest.java 文件
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class MyTest {
private static final Logger LOGGER = LoggerFactory.getLogger(MyTest.class);
public static void main(String[] args) {
LOGGER.info("logback 测试");
}
}
以上咱们就把日志依赖的 jar 导入到了项目,现在项目就可以使用日志了.
logback 下的两个包为 logback 依赖的 jar 包,由于依赖的传递性,所以目前项目的测试代码也依赖了这两个包,比如slf4j.
如果此项目引入了其他的 jar 包,而这些 jar 也依赖了slf4j,但是版本不一样的情况下就存在了版本冲突问题,像版本冲突在开发中是经常遇到的,那么在 Gradle 中如何解决版本冲突呢? 请期待下一篇 <