Gradle-user guide-第8章 依赖管理基础(译)

本文介绍了Gradle中的依赖管理基础知识,包括依赖与发布的概念、依赖的声明与配置、外部依赖及仓库的使用,以及如何发布产物。

第8章依赖管理基础

这章会介绍一些Gradle中的依赖管理的基础知识。

8.1什么是依赖管理

粗略地说,依赖由两方面组成。第一,Gradle需要知道项目要构建或者执行的东西,以便于可以找到它们,我们把这些项目需要的文件称作项目的依赖。第二,Gradle需要构建和上传项目所生成的东西,我们把生成的文件叫做项目的发布。让我们来在更多细节上看看这两方面。

大多数项目都不是完全独立的。它们需要其他项目构建的文件来被编译、测试等。例如,为了在项目中使用Hibernate ,需要在classpath中加入一些Hibernatejar文件;为了测试项目,需要在test classpath中加入一些额外的jar文件,比如说一个特定的JDBC驱动或者Ehcache JAR文件。 

这些文件就是项目的依赖。Gradle需要你告知它项目的依赖是什么,以便于它可以找到这些依赖,并使这些依赖在项目中是可用的。这些依赖可能需要从远程的Mavenlvy仓库下载,或者是从本地目录加载,或者当在一个多项目构建中时,依赖也可能是被其他项目构建出来的。我们称这个过程为“依赖解决”(dependency resolution)

经常地,项目的依赖本身会存在其他的依赖。举个例子,Hibernate 核心库需要在其classpath中申明依赖一些其他的库,才能够运行。因此,Gradle测试为你的项目执行测试的时候,它需要找到这些依赖,并使它们是可用的。我们称之为过渡依赖transitivedependencies)。

大多数项目的主要目的是构建出一些在本身项目之外的地方可以使用的文件。例如,如果你的项目产生一个java库,那么你需要去构建一个jar文件,可能也会需要去构建一个包含源代码的jar文件,以及一些注视文档,并且在某些地方去发布它们。

这些输出文件组成了项目的发布。Gradle会小心的为你处理这重要的工作,你申明你的项目的发布,Gradle会构建它们并且在发布它们。确切来说,发布(publishing)代表你想要去做的事情。你可能想要将文件拷贝到本地目录,或者是将它们上传到远程的Mavenlvy仓库,或者是你可能在多项目构建中的另一个项目中使用这些文件。我们将这个过程称为发布(publication)。

8.2申明依赖

让我们来看一下依赖的申明。这里有个基础的构建脚本:

例子8.1申明依赖

applyplugin: 'java'
 
repositories{
    mavenCentral()
}
 
dependencies{
    compile group:'org.hibernate',name:'hibernate-core',version:'3.6.7.Final'
    testCompile group:'junit',name:'junit',version:'4.+'
}

这里发生了什么呢?这个构建脚本描述了一些关于项目的内容。首先,申明需要hibernate核心库3.6.7.Final来编译项目代码。隐含地,在运行时需要hibernate核心库的依赖。构建脚本也同时申明依需要一个版本大于等于4.0junit来编译项目的测试代码。构建脚本也告知去Maven中心仓库查找任何依赖。接下里会进行详细的说明。

8.3依赖配置

依赖被分到配置里面,一项配置可以简单地称为一系列的依赖,我们称为依赖配置。你可以用它们申明项目的外部依赖。正如我们稍后将会看到的,它们也被用来申明项目的发布。

Java插件定义了许多标准的配置,这些配置描述了Java插件所使用的类路径(classpaths)。

下面列出了一些依赖配置项。

编译(compile

编译项目源代码所需要的依赖。

运行时(runtime

classes在运行时所需要的依赖,默认包含编译时依赖。

测试编译(testCompile

编译项目测试代码所需要的依赖,默认包含classes和编译时依赖。

测试运行时(testRuntime

执行测试所需要的依赖。默认包含编译、运行时、测试编译依赖。

各种插件添加进一步的标准配置。你也可以定义自定义配置。依赖配置中的定义和定制依赖配置的更多细节参考50.3部分。

8.4外部依赖

有许多类型的依赖是可以被定义的。外部依赖就是其中的一种。这种依赖的对象不在当前的构建项目中,它们在远程仓库或者是本地文件系统的一个目录中。

将如下代码添加到依赖配置中,就可以定义一个外部依赖。

例子8.2外部依赖的定义

dependencies{
   compile group : 'org.hibernate', name: 'hibernate-core', version:'3.6.7.Final'
}

外部依赖定义使用group、name、version属性。根据所使用的库不同,group和version是可选的。

有一种定义外部依赖的快捷方式,使用"group:name:version"格式的字符串。

例子8.3外部依赖的快捷定义

dependencies{
   compile 'org.hibernate:hibernate-core:3.6.7.Final'
}

8.5仓库

Gradle是如何从外部依赖找到文件的呢?Gradle从仓库(repository)中寻找它们。仓库实际上是一堆文件的集合,这些文件通过group、name、version组织分类。Gradle支持很多仓库,比如Maven和Ivy,而且有不同的方式访问仓库,比如本地文件系统和HTTP。

默认地,Gradle没有定义任何仓库,在使用外部依赖之前,你需要定义至少一个仓库。一种选择是使用Maven central仓库。

例子8.4 使用 Maven central仓库

repositories{
   mavenCentral()
}

也可以使用远程的Maven仓库

例子8.5使用远程Maven仓库

repositories{
   maven{
       url "http://repo.mycompany.com/maven2"
    }
}

一个项目可能有多个仓库,Gradle会根据库的定义顺序来依次找到对应的依赖,如果找到了依赖,那么就不会在后面定义的仓库中寻找了。

 

8.6 发布产物

依赖位置也用来发布文件,这些文件被称为发布产物(publishing artifacts),或者通常称为产物(artifacts)。

插件做了一项很好的工作,定义项目的产物。因此你不需要告诉Gradle哪些需要发布。但是,你需要告诉Gradle将产物发布到哪个地方。方法是把库附在uploadArchives任务里。下面是一个发布到远程Ivy仓库的例子:

例子8.8发布到Ivy仓库

uploadArchives {
   repositories {
       ivy {
           credentials {
                username "username"
                password "pw"
           }
            url"http://repo.mycompany.com"
       }
    }
}

现在,当你执行Gradle uploadArchives,Gradle就会构建和上传你的Jar,Gradle也会生成一个Ivy.xml文件,并且也会将它与Jar文件一同上传。

你也可以发布到Maven仓库,语法有一点点不同,因为发布到Maven仓库需要应用Maven插件。这种情况下,Gradle会生成和上传一个pom.xml文件。

例子8.9发布到Maven仓库

apply plugin: 'maven'
 
uploadArchives {
   repositories {
       mavenDeployer {
           repository(url: "file://localhost/tmp/myRepo/")
       }
    }
}

<think>好的,用户遇到了无法找到kotlin-compiler-embeddable-2.0.20.jar的问题,使用Gradle 8.11.1和Kotlin DSL。我需要先分析可能的原因,然后给出解决方案。 首先,这个JAR文件属于Kotlin编器的一部分。版本号2.0.20看起来有问题,因为Kotlin的版本通常和Gradle插件版本对应。例如,Kotlin 1.5.21对应的是不同的编器版本。用户可能配置了错误的Kotlin版本,或者Gradle插件版本不匹配。 检查用户提供的引用内容,引用[1]提到Kotlin插件版本1.5.21,而引用[2]讨论了Groovy和Kotlin DSL的区别。用户的问题可能源于版本不兼容,尤其是当Kotlin插件版本与Gradle版本不匹配时。 可能的解决方案包括: 1. 更新Kotlin插件到与Gradle 8.11.1兼容的版本。查看Gradle官方文档,确认支持的Kotlin版本。例如,Gradle 8.x通常需要较新的Kotlin版本,比如1.8.x或更高。 2. 确保构建脚本中的仓库配置正确,比如使用Maven Central或Google仓库,确保能正确下载依赖。 3. 清理Gradle缓存,有时候旧版本或损坏的缓存文件会导致问题。 4. 检查依赖声明是否有误,比如是否错误地引用了不存在的版本,或者模块名称拼写错误。 用户提到的kotlin-compiler-embeddable-2.0.20.jar中的2.0.20可能是一个笔误,因为Kotlin编器版本通常与插件版本一致,比如1.5.21对应的编器版本应该是1.5.x,而不是2.0.x。因此,用户可能错误地指定了版本号,或者某个依赖传递引入了错误的版本。 需要指导用户检查build.gradle.kts中的Kotlin插件版本,并更新到兼容的版本。同时,确保仓库配置正确,并清理缓存。另外,可能需要检查是否有其他依赖引用了旧版本的Kotlin组件,导致冲突。</think>### 解决方案步骤 #### 1. 确认版本兼容性 Kotlin插件版本需与Gradle版本严格匹配。根据[Gradle官方兼容性文档](https://docs.gradle.org/current/userguide/compatibility.html)Gradle 8.11.1建议使用Kotlin插件**1.8.20+**。若项目中使用了过时的Kotlin版本(如1.5.21),会导致依赖解析失败。 修改`build.gradle.kts`中的插件版本: ```kotlin plugins { kotlin("jvm") version "1.8.22" // 更新至兼容版本 } ``` #### 2. 检查仓库配置 确保构建脚本中包含Maven Central或官方仓库: ```kotlin repositories { mavenCentral() google() // 若使用Android相关库 } ``` #### 3. 清理Gradle缓存 执行以下命令清理本地缓存: ```bash ./gradlew clean build --refresh-dependencies ``` #### 4. 验证依赖树 通过以下命令检查是否存在版本冲突: ```bash ./gradlew dependencies --configuration kotlinCompilerClasspath ``` 若发现`kotlin-compiler-embeddable`被错误地指定为2.0.20,需排查具体引入该版本的依赖项。 #### 5. 强制指定版本(备用方案) 在`build.gradle.kts`中添加强制版本约束: ```kotlin configurations.all { resolutionStrategy { force("org.jetbrains.kotlin:kotlin-compiler-embeddable:1.8.22") } } ``` ### 根本原因分析 `kotlin-compiler-embeddable-2.0.20.jar`不存在于官方仓库中,Kotlin编器版本号实际遵循**主版本.次版本.补丁**模式(如1.8.22)。此问题通常由以下原因导致: 1. 构建脚本中显式声明了不存在的版本 2. 第三方插件传递依赖了错误的Kotlin版本 3. Gradle版本与Kotlin插件版本不兼容[^1] ### 附加建议 - 使用Gradle版本目录统一管理依赖版本(推荐): ```kotlin // settings.gradle.kts dependencyResolutionManagement { versionCatalogs { create("libs") { library("kotlin-stdlib", "org.jetbrains.kotlin:kotlin-stdlib:1.8.22") } } } ``` - 定期使用`./gradlew dependencyUpdates`检查依赖更新
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值