gradle 3.0.0-alphaX 的库依赖问题

Question

我有一个包含子模块的库项目，其中包含许多我想传递给开发人员应用程序的依赖项。例如，模块 A 可能包含所有必需的 appcompat 依赖项。

对于 migration changes，我已将所有 compile 个案例更新为 api，这应该不会有任何影响。但是，我无法再访问任何库依赖项。我只能使用我的库本身的代码和引用。

有什么解决办法吗？

可以找到我的库子模块的构建 gradle 文件之一 here 以供参考。

依赖项：

dependencies {
    api "org.jetbrains.kotlin:kotlin-stdlib:${KOTLIN}"

    api "com.android.support:appcompat-v7:${ANDROID_SUPPORT_LIBS}"
    api "com.android.support:support-v13:${ANDROID_SUPPORT_LIBS}"
    api "com.android.support:design:${ANDROID_SUPPORT_LIBS}"
    api "com.android.support:recyclerview-v7:${ANDROID_SUPPORT_LIBS}"
    api "com.android.support:cardview-v7:${ANDROID_SUPPORT_LIBS}"
    api "com.android.support.constraint:constraint-layout:${CONSTRAINT_LAYOUT}"

    api "com.mikepenz:iconics-core:${ICONICS}@aar"
    api "com.mikepenz:google-material-typeface:${IICON_GOOGLE}.original@aar"

    api "com.afollestad.material-dialogs:core:${MATERIAL_DIALOG}"

    api "com.jakewharton.timber:timber:${TIMBER}"

    api "org.jetbrains.anko:anko-commons:${ANKO}"
}

编辑：

澄清一下，模块中的示例项目实际上可以正确构建，但是在任何其他应用程序中使用依赖项存在问题，它从 jitpack 中提取。请参阅 this gradle 作为无法构建的示例。我试过使用 api、实现、@aar 和传递的组合。

仔细想想，这可能是一个 jitpack 问题，而不是 gradle 问题，但如果有人有解决方案，我想听听。

Answer 1

它已在 android-maven-gradle-plugin

的“2.0”版本中修复

刚更新到

dependencies {
        classpath 'com.github.dcendents:android-maven-gradle-plugin:2.0'
}

或使用自 Gradle 2.1

以来的新语法

plugins {
  id "com.github.dcendents.android-maven" version "2.0"
}

在你的库模块中使用api允许你在你的库代码中仅访问临时依赖；而不是使用它的应用程序。

因此，为了达到预期效果，您需要更改示例模块。

implementation project(':core')

到

api project(':core')

注意你不需要在你的库中使用 api 最好使用 implementation 因为它可以加速你的构建。

Answer 2

这个问题似乎与 android-maven-gradle-plugin

有关

我ssue Report

Answer 3

I no longer have access to any of the libraries dependencies. I can only use code and references from my library itself.

正确。

来自gradle docs :

dependencies {
    api 'commons-httpclient:commons-httpclient:3.1'
    implementation 'org.apache.commons:commons-lang3:3.5' 
}
Dependencies appearing in the api configurations will be transitively exposed to consumers of the library, and as such will appear on the compile classpath of consumers.

Dependencies found in the implementation configuration will, on the other hand, not be exposed to consumers, and therefore not leak into the consumers' compile classpath. This comes with several benefits:

dependencies do not leak into the compile classpath of consumers anymore, so you will never accidentally depend on a transitive dependency

faster compilation thanks to reduced classpath size

less recompilations when implementation dependencies change: consumers would not need to be recompiled

cleaner publishing: when used in conjunction with the new maven-publish plugin, Java libraries produce POM files that distinguish exactly between what is required to compile against the library and what is required to use the library at runtime (in other words, don't mix what is needed to compile the library itself and what is needed to compile against the library).

gradle 3.0.0-alphaX 的库依赖问题

Library dependency issues with gradle 3.0.0-alphaX

android

gradle

build.gradle

android-gradle-plugin

jitpack