gow*_*672 6 android gradle gradle-kotlin-dsl
我有一个库模块。它正在使用来自的库
allprojects {
repositories {
maven {
url = uri("https://jitpack.io/")
}
}
}
Run Code Online (Sandbox Code Playgroud)
仅当我在项目级别 build.gradle 中添加 jitpack 依赖项时,同步才会成功。现在,我不想强迫我的库用户在其项目级别 build.gradle 中添加 jitpack 依赖项。所以,我试图在库模块本身中添加存储库。
我在我的库中尝试了以下代码。
plugins {
id("com.android.library")
}
repositories {
google()
maven {
url = uri("https://jitpack.io/")
}
}
android {
// ...
}
dependencies {
// from jitpack
implementation("https://github.com/a914-gowtham/compose-ratingbar")
// ...
}
Run Code Online (Sandbox Code Playgroud)
构建拥有并且必须拥有对其直接和传递依赖的依赖关系的完全控制权。
例如,JitPack 在设计上就破坏了正确发布的用例,并且并不真正适合该用例。它仅适合快速尝试一些中间版本。除此之外,它非常慢,特别是当首先请求版本时,甚至可能使构建工具超时并记住 JitPack 没有依赖性。我也见过它的各种中断。除此之外,它还操纵它提供的库,从而严重破坏了一些库。...
这些是某些版本的原因,例如您的库的用户可能更喜欢从另一个地方获取依赖项,例如他自己的存储库服务器,他在其中部署了他需要的所有库。
另一个原因可能是公司准则强制规定不得使用公共服务器来获取依赖项,例如由于中断风险或添加恶意内容的风险,...
甚至可能有代理后面的网络禁止此类外部请求,只允许具有所需依赖项的内部存储库。
或者,架构师可能想要控制允许哪些库将其纳入构建的产品中。
项目应该完全控制哪些存储库用于从中提取直接依赖项和传递依赖项有很多原因,我列出了其中的一些原因,您可以理解为什么会出现这种情况。
由于这些原因,您的库的使用者必须指定从其自身提取依赖项的存储库,无论是 JitPack 还是合理的替代方案。
PS:任何使用allprojects { ... }或subprojects { ... }都是代码异味,应该避免。您应该改用约定插件。
| 归档时间: |
|
| 查看次数: |
289 次 |
| 最近记录: |