![f8e44c7cec0247ae4475ef1a3eeb73fa.png](https://i-blog.csdnimg.cn/blog_migrate/6cc9a62c2fd81e5b9df18c43ff5d0c3c.png)
什么是依赖管理?
通俗来讲,依赖管理由如下两部分组成。首先,Gradle 需要知道项目构建或运行所需要的一些文件,以便于找到这些需要的文件。我们称这些输入的文件为项目的依赖。其次,你可能需要构建完成后自动上传到某个地方。我们称这些输出为发布。下面来仔细介绍一下这两部分:
大部分工程都不太可能完全自给自足,一般你都会用到其他工程的文件。比如我工程需要 Hibernate 就得把它的类库加进来,比如测试的时候可能需要某些额外 jar 包,例如 JDBC 驱动或 Ehcache 之类的 Jar 包。
这些文件就是工程的依赖。Gradle 需要你告诉它工程的依赖是什么,它们在哪,然后帮你加入构建中。依赖可能需要去远程库下载,比如 Maven 或者 Ivy 库。也可以是本地库,甚至可能是另一个工程。我们称这个过程叫依赖解决。通常,依赖的自身也有依赖。例如,Hibernate 核心类库就依赖于一些其他的类库。所以,当 Gradle 构建你的工程时,会去找到这些依赖。我们称之为依赖传递。
大部分工程构建的主要目的是脱离工程使用。例如,生成 jar 包,包括源代码、文档等,然后发布出去。这些输出的文件构成了项目的发布内容。
Gralde 也会为你分担这些工作。你声明了发布到到哪,Gradle 就会发布到哪。“发布”的意思就是你想做什么。比如,复制到某个目录,上传到 Maven 或 Ivy 仓库。或者在其它项目里使用,这些都可以称之为发行。
依赖声明
来看一下这个脚本里声明依赖的部分:
在 build.gradle 文件中
apply plugin: 'java'
repositories {
mavenCentral()
}
dependencies {
compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final'
testCompile group: 'junit', name: 'junit', version: '4.+'
}
//外部依赖包含 group,name 和 version 几个属性。根据选取仓库的不同,group 和 version 也可能是可选的。
//当然,也有一种更加简洁的方式来声明外部依赖。采用:将三个属性拼接在一起即可。"group:name:version"
// 快速定义外部依赖
dependencies {
compile 'org.hibernate:hibernate-core:3.6.7.Final'
}
这是什么意思呢?这段脚本是这么个意思。首先,Hibernate-core.3.6.7.final.jar 这货是编译期必需的依赖。并且这货相关的依赖也会一并被加载进来,该段脚本同时还声明项目测试阶段需要 4.0 版本以上的 Junit。同时告诉 Gradle 可以去 Maven 中央仓库去找这些依赖。
依赖声明的版本和范围
- 一个确切的版本:比如1.3,1.3.0-beta3,1.0-20150201.131010-1
- 一个Maven风格的版本范围:例如[1.0,),[1.1, 2.0),(1.2, 1.5]
- [和]符号表示结合的包括端点; (并)指出排他性界限。
- 如果缺少上限或下限,则范围没有上限或下限。
- 符号]可以被用来代替(用于排他性下界,并且[代替的)专用上限。例如]1.0, 2.0[
- 一个前缀版本范围:例如1.+,1.3.+
- 仅包含与之前部分完全匹配的版本+。
- +本身的范围将包括任何版本。
- 一个 latest-status 版本:例如 latest.integration,latest.release
- 将使版本最高的模块与指定状态匹配。请参阅 ComponentMetadata.getStatus()。
- Maven SNAPSHOT版本标识符:例如 1.0-SNAPSHOT,1.4.9-beta1-SNAPSHOT
文件依赖
dependencies {
runtimeOnly files('libs/a.jar', 'libs/b.jar')
runtimeOnly fileTree('libs') { include '*.jar' }
}
文件依赖项不包含在项目的已发布依赖项描述符中。但是,文件依赖关系包含在同一构建中的可传递项目依赖关系中。这意味着它们不能在当前版本之外使用,但可以在同一版本内使用。
项目依赖
dependencies {
implementation project(':shared')
}
在运行时,该构建会自动确保以正确的顺序构建项目依赖项,并将其添加到类路径中进行编译。
依赖配置
Java 插件定义了许多标准配置项。这些配置项形成了插件本身的 classpath。
- compile 编译范围依赖在所有的 classpath 中可用,同时它们也会被打包
- runtime runtime 依赖在运行和测试系统的时候需要,但在编译的时候不需要。比如,你可能在编译的时候只需要 JDBC API JAR,而只有在运行的时候才需要 JDBC 驱动实现
- testCompile 测试期编译需要的附加依赖
- testTuntime 测试运行期需要
仓库
Gradle 是在一个被称之为仓库的地方找寻所需的外部依赖。仓库即是一个按 group,name 和 version 规则进行存储的一些文件。Gradle 可以支持不同的仓库存储格式,如 Maven 和 Ivy,并且还提供多种与仓库进行通信的方式,如通过本地文件系统或 HTTP。 默认情况下,Gradle 没有定义任何仓库,你需要在使用外部依赖之前至少定义一个仓库,例如 Maven 中央仓库。
远程仓库
- 使用Maven中央仓库
//在 build.gradle 文件中
repositories {
mavenCentral()
}
// 或者其它远程 Maven 仓库:
// 使用 Maven 远程仓库
repositories {
maven {
url "http://repo.mycompany.com/maven2"
}
}
- 采用IVY远程仓库
//在 build.gradle 文件中
repositories {
ivy {
url "http://repo.mycompany.com/repo"
}
}
// 采用本地 Ivy 目录
repositories {
ivy {
// URL can refer to a local directory
url "../local-repo"
}
}
私服:一般是由公司自己设立的,只为本公司内部共享使用。它既可以作为公司内部构件协作和存档,也可作为公用类库镜像缓存,减少在外部访问和下载的频率。(使用私服为了减少对中央仓库的访问)
一个项目可以采用多个库。Gradle 会按照顺序从各个库里寻找所需的依赖文件,并且一旦找到第一个便停止搜索。
Gradle 加载本地 jar 包
- 加载单独的 jar 包
有时,我们需要的 jar 包不一定能在远程仓库中找到,这时我们需要加载本地的 jar 包。 在项目底下添加 libs 目录,将 jar 包仍进 libs 目录
//build.gradle配置如下:
dependencies {
compile files('lib/ojdbc-14.jar')
}
- 加载某个目录的jar包
在自己的 Gradle 项目里建立一个名为 libs (这个名字可以自己定义,不一定非要叫这个名字)的文件夹,把自己本地的 jar 包拷贝到这个文件夹中。
//build.gradle配置如下:
dependencies {
compile fileTree(dir:'libs',include:['*.jar'])
}
打包发布
依赖配置被用于发布文件的操作也称之为打包发布或发布。 插件对于打包提供了完美的支持,所以通常而言无需特别告诉 Gradle 需要做什么。但是你需要告诉 Gradle 发布到哪里。这就需要在 uploadArchives 任务中添加一个仓库。
- 发布到 lvy 仓库
//在 build.gradle 文件中
uploadArchives {
repositories {
ivy {
credentials {
username "username"
password "pw"
}
url "http://repo.mycompany.com"
}
}
}
执行 gradle uploadArchives,Gradle 便会构建并上传你的 jar 包,同时会生成一个 ivy.xml 一起上传到目标仓库。
- 发布到 Maven 仓库
发布到 Maven 仓库你需要 Maven 插件的支持,当然,Gradle 也会同时产生 pom.xml 一起上传到目标仓库。
//在 build.gradle 文件中
apply plugin: 'maven'
uploadArchives {
repositories {
mavenDeployer {
repository(url: "file://localhost/tmp/myRepo/")
}
}
}
maven中央仓库依赖搜索
https://blog.csdn.net/weixin_34850743/article/details/99753659