android - 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

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).

---