Library dependency issues with gradle 3.0.0-alphaX

Question

I have a library project with submodules that include many dependencies that I'd like to pass to the developer's application. For example, module A may include all the necessary appcompat dependencies.

With the migration changes, I've updated all compile cases to api, which should not affect anything. However, I no longer have access to any of the libraries dependencies. I can only use code and references from my library itself.

Is there any way around this?

One of the build gradle files of my library submodules can be found here for reference.

The dependencies:

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}"
}

Edit:

To clarify, the sample project in the module actually does build properly, but there's an issue with using the dependencies in any other app, where it pulls from jitpack. See this gradle as an example that won't build. I've tried using combinations of api, implementation, @aar, and transitive.

Come to think of it, this may be a jitpack issue and not a gradle issue, but if anyone else has a resolution I'd like to hear it.

I has this issue with bazel. Don't sure how to fix this issue with gradle but you can google it with keywords "transient dependencies". Obviously, the easiest way is to provide all dependencies that your module needs directly in module build.gradle. — useless dinosaur, Aug 01 '17 at 20:41
@uselessdinosaur there may be more to it. I've tried transitive dependencies and it didn't seem to work, but upon closer inspections and from the answer below, this may be a jitpack specific issue — Allan W, Aug 02 '17 at 01:39

score 1 · Answer 1 · answered Aug 19 '17 at 18:50

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

It is correct.

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

This ended up being an issue with the dcendants maven plugin. Having everything with api was a test to see if it would work, and it should have behaved exactly as the old compile option. — Allan W, Aug 20 '17 at 03:08

humazed · Answer 2 · 2017-09-03T11:44:28.607

0

It's has been fixed in version "2.0" of android-maven-gradle-plugin

just update to

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

or using the new syntax since Gradle 2.1

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

using api in your library module allows you to access the transient dependencies only in your library code; not the apps that consume it.

so to achieve the desired effect you need to change in your sample module.

implementation project(':core')

to

api project(':core')

note you don't need to use api in your library it's better to use implementation as it speeds up your build.

edited Sep 03 '17 at 11:44

answered Aug 01 '17 at 20:56

humazed

74,687
32
99
138

It actually works with the sample app, but not with other apps which pull from jitpack. Additionally, why should a sample model use `api` rather than `implementation`? It has no need to pass out another interface to another package. I'm considering moving the project dependencies to implementations, but it will mean that those who want to pick one specific project will need to add the other dependencies themselves. But regardless, since `api` isn't working, I'm not at that stage yet. – Allan W Aug 01 '17 at 22:41

score 0 · Accepted Answer · answered Aug 19 '17 at 18:40

0

The issue seems to be related to the android-maven-gradle-plugin

Issue Report

answered Aug 19 '17 at 18:40

Allan W

2,791
4
23
41

It's has been fixed in version "2.0" – humazed Sep 03 '17 at 11:45

Library dependency issues with gradle 3.0.0-alphaX

3 Answers3