maven_aar dependency cannot include transitive dependency

[SteveMunday]

Description of the problem / feature request / question:

I'm trying to convert a fairly sizeable Android app build from Gradle to Bazel, to better manage our mono-repo. The app has a number of library dependencies including 2 aar's, and I'm having trouble building this library: https://github.com/ArthurHub/Android-Image-Cropper
I found the maven_aar build rule and have implemented that correctly (I think). Even so, I'm getting errors from aapt validating resources in this library. This library builds and runs using Gradle.

If possible, provide a minimal example to reproduce the problem:

Here it is, building this will produce the error.
https://github.com/SteveMunday/bazel_aar_test

Environment info

• Operating System:
  MacOS Sierra 10.12.2

• Bazel version (output of bazel info release):
  Built from source at: bc133cb

Have you found anything relevant by searching the web?

This StackOverflow answer references a similar error message, which indicates that we might be missing the appcompat-v7 library, but I confirmed that this is correctly imported. It's an older answer so the compileSdkVersion is no longer relevant.
No Resource Identifier found error,

I thought this might be related, which was why I tried building from source. I did everything suggested here, no help.
appcompat-v7 support library missing,

This is what I referenced for how to use maven_aar:
maven_aar

Anything else, information or logs or outputs that would be helpful?

Complete Bazel log output:
https://gist.github.com/SteveMunday/903f4e1e526119a004c8bcb47bb0dc16

[aj-michael]

Hi @SteveMunday, first of all thank you for the very detailed report.

The error that you are seeing is when bazel attempts to process the resources contained in the AAR. Note that bazel build @android_image_cropper//aar also produces this error.

The problem is that the AAR from Jcenter itself depends on appcompat-v7. You can see that in http://jcenter.bintray.com/com/theartofdev/edmodo/android-image-cropper/2.3.1/android-image-cropper-2.3.1.pom Your BUILD file makes and android_library and an android_binary depend on appcompat-v7, but @android_image_cropper//aar is an aar_import rule that itself has no dependencies. Sadly, this is currently a limitation of maven_jar and maven_aar: they do not pull in transitive dependencies. You can see some discussion of this in #1410.

Unfortunately this is not something that you will be able to do with the maven_aar rule right now. I suppose I should probably add a deps attribute to maven_aar that it would pass through to the aar_import that it creates. Alternatively, you could download the AAR from http://jcenter.bintray.com/com/theartofdev/edmodo/android-image-cropper/2.3.1 and use the aar_import rule (see https://bazel.build/versions/master/docs/be/android.html#aar_import) in a BUILD file. If you do not want to check the file into your repository, you could use the http_file rule to download the AAR from jcenter.

Workaround with http_file:

# WORKSPACE
android_sdk_repository(name = "androidsdk")  # Reads $ANDROID_HOME
http_file(
    name = "android_image_cropper_2_3_1_aar",
    url = "http://jcenter.bintray.com/com/theartofdev/edmodo/android-image-cropper/2.3.1/android-image-cropper-2.3.1.aar",
    sha256 = "8f559a788431fe6c52b2d81a29df8ace05a780ea8c0350095954f1b0ce85cf0a",
)

# BUILD
aar_import(
    name = "android_image_cropper",
    aar = "@android_image_cropper_2_3_1_aar//file",
    deps = ["@androidsdk//com.android.support:appcompat-v7-24.1.1"],
)
android_library(
    name = "activities",
    srcs = glob(["app/src/main/java/**/*.java"]),
    custom_package = "com.example.bazel_aar_test",
    manifest = "app/src/main/AndroidManifest.xml",
    resource_files = glob(["app/src/main/res/**"]),
    deps = [
        "//:android_image_cropper",
        ...other deps...
    ],
)

For the maven_jar case, this is not as much of a problem because JARs on maven are typically compiled and require no further processing by Bazel. But AARs contain "uncompiled resources", so maven_aar really should be able to specify deps.

Maybe @kchodorow can comment on the future of/prioritization of transitive maven rules and if it would be a reasonable idea to add a deps attribute to the skylark maven_jar and maven_aar.

[aj-michael]

(Oops, did not mean to close.)

[SteveMunday]

Submit a detailed report, receive a detailed answer. 😄

Thanks for suggesting a workaround with an http_library rule, I think I'll do that. I'd rather not maintain my own fork of this library. I'll see if the maintainer will accept a pull request with a BUILD file so that I can go back to using maven_aar. Since appcompat-v7 a very common library, this is probably a pretty common scenario for users of maven_aar.