首页 > 技术文章 > Java系列文章 >

Gradle项目依赖管理

更新时间:2018-11-02 | 阅读量(2,958)

上一篇咱们讲解了 Gradle 构建项目的生命周期,这一篇咱们来看下 Gradle 的另一个重要的知识点,就是依赖管理,那为什么需要依赖管理呢? # 依赖管理 几乎所有基于 JVM 的软件项目都需要依赖外部的类库来重用现有的功能代码.自动化依赖管理可以明确依赖的版本,能解决传递性依赖带来的版本冲突问题. 而Gradle 就满足这两个条件,以下就来看下依赖管理的关键点. ## 依赖管理关键点 ### 1.工件坐标(jar 包标志): + group : 指明 jar 包所在的分组 + name : 指明 jar 包的名称 + version: 指明 jar 包的版本 ``` dependencies { testCompile group: 'junit', name: 'junit', version: '4.12' // 简写 // testCompile 'junit:junit:4.12' } ``` 在 dependencies 中指明依赖的 jar 包 ### 2. 仓库(jar 包的存放位置) + 公共仓库(中央仓库) Gradle 没有自己的中央仓库,可配置使用 Maven 的中央仓库:mavenCentral/jcenter + 私有仓库 配置从本地 maven 仓库中获取依赖的 jar 包,不远程加载 jar 包,使用 mavenLocal + 自定义 maven 仓库 自定义仓库来源,一般指向公司的 Maven 私服.(普片做法) + 文件仓库 本地机器上的文件路径,一般不使用,没有意义,因为构建工具的目的就是去除本机的影响,可以在任何地方公用同一份仓库数据,跟本机关联上就没有太大的意义,当然特殊情况下除外. ``` repositories { // 配置本地仓库 mvaenLocal() // 配置中央仓库 // jcenter() mavenCentral() // 自定义私服地址 maven { url '' } } ``` 在 repositories 中配置仓库的指向,在这里面可配置多个仓库,会按配置的顺序去查找jar包,找到则获取,找不到继续到下一个配置的仓库去查找.一般是在最前面配置公司的私服,使用自定义仓库方式配置. ### 3. [依赖传递性]() 比如: A 依赖 B,如果 C 依赖 A,那么 C 依赖 B 就是因为依赖的传递性,所以才会出现版本的冲突问题.以下通过一张图来了解下Gradle 的自动化依赖管理流程. ![image.png](https://upload-images.jianshu.io/upload_images/9082898-9917c95f37a0278e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240) 由图可得知,Gradle 工具从远程仓库下载 jar 包到本地仓库,Gradle 工具需要依赖配置文件,如果同一个 jar 经常使用会被存入到依赖缓存中. ### 4.依赖阶段配置 在 build.gradle 中的 dependencies 中配置依赖,依赖分以下四种依赖. 源码依赖: compile , runtime 测试依赖: testCompile, runtime 关系图如下: ![image.png](https://upload-images.jianshu.io/upload_images/9082898-26e8cdff68bb37bb.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240) + compile 配置依赖的 jar ,测试代码编译和运行以及源码运行一定存在. ![image.png](https://upload-images.jianshu.io/upload_images/9082898-d8a6f5e903a2b66c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240) + runtime 配置依赖的 jar,只有源码运行和测试运行存在. ![image.png](https://upload-images.jianshu.io/upload_images/9082898-371a9bb753b27700.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240) + testCompile 配置依赖的 jar,测试代码的编译和运行存在. ![image.png](https://upload-images.jianshu.io/upload_images/9082898-8e144de1bfa2b88e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240) + testRuntime 配置依赖的 jar,只有测试代码的运行存在. ![image.png](https://upload-images.jianshu.io/upload_images/9082898-05046e4e3d6d0fba.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240) `以上的四种配置选用的主要判断依据是是否仅是运行阶段需要依赖或是否仅是测试阶段需要依赖`. 仅运行阶段需要依赖使用 runtime ,如果仅是测试阶段需要依赖加 test 前缀 testCompile 或 testRuntime. 以上是依赖管理的配置和概念点的讲解,接下来咱们来实际配置一个依赖,来为项目加入一个logbok依赖. ### 5. 加入 logbok 依赖 5.1 到中央仓库查找 logbok 的配置 [http://mvnrepository.com/search?q=logback](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 刷新导入 ![image.png](https://upload-images.jianshu.io/upload_images/9082898-cf9f4e0915796a61.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240) 在 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 中如何解决版本冲突呢? 请期待下一篇 <>
叩丁狼学员采访 叩丁狼学员采访
叩丁狼头条 叩丁狼头条
叩丁狼在线课程 叩丁狼在线课程