Unresolved reference from gradle maven dependency via s3

Question

I try to publish a library to a private S3 maven repository. The upload is guarded by a password, but for download the library is open for public. The aar file uploads without issues (along with pom/md5/sha1) and I can see it in my S3 bucket, download it and even manually add this aar as dependency to my project. However when I load this dependency like this:

allprojects {
    repositories {
        google()
        jcenter()
        maven { url "http://myrepo.com" }
}

//in the project's build.gradle
implementation 'com.mylib:mylib:0.1.1'

...there is an issue. Gradle sync finishes without a problem and it looks like the aar has been downloaded, but it never appears in the "External Libraries" section inside Android Studio, and the code is not available (Unresolved reference: MyLib).

Of course I tried rebuilding, invalidating caches and applying it to a different project.

Any ideas how to make it work?

This is how the maven-publish code looks.

android.libraryVariants.all { variant ->

    if (variant.buildType.name == "release" && variant.flavorName == "prod") {

        variant.outputs.all { output ->

            publishing.publications.create(variant.name, MavenPublication) {

                artifact source: output.outputFile, classifier: output.name

                pom.withXml {
                    def dependencies = asNode().appendNode('dependencies')

                    configurations.getByName(variant.name + "CompileClasspath").allDependencies
                            .findAll { it instanceof ExternalDependency }
                            .each {
                        def dependency = dependencies.appendNode('dependency')

                        dependency.appendNode('groupId', it.group)
                        dependency.appendNode('artifactId', it.name)
                        dependency.appendNode('version', it.version)

                    }
                }
            }
        }

    }
}

tasks.all { task ->
    if (task instanceof AbstractPublishToMaven) {
        task.dependsOn assemble
    }
}

publishing {

    Properties properties = new Properties()
    properties.load(file('maven.properties').newDataInputStream())

    def user = properties.getProperty("maven.user")
    def password = properties.getProperty("maven.password")

    repositories {
        maven {
            url "s3://myrepo.com/"
            credentials(AwsCredentials) {
                accessKey user
                secretKey password
            }
        }
    }
}

Tortile

what happens if you delete the line maven { url "http://myrepo.com" } and clean build. (to sanity check / make sure it is doing something) You should get a not found error, meaning the DL works – Underclothing

@Underclothing its says Failed to resolve: mylib:mylib:0.1.1 – Beeeater

doesn't sound like pulling in the dep is the problem. Perhaps its a problem with the generated aar you uploaded to your nexus, or what classes are compiled visible / perhaps proguard removed them all as there are no references :) etc – Underclothing

@Underclothing Definitely the aar itself is fine, because I can download it manually from my bucket and apply it to the app and it works perfect. I disabled proguard. It seems like a problem with the structure or naming of my files in the s3 bucket. But I have no idea how a proper structure should look like. – Beeeater

Answer 1

Apparently those deployment plugin (both this and the bintray one, too) have some major difficulties when flavors get involved. I don't know the specifics, but it has something to do with them trying to resolve the artifact names based on filenames. This line:

artifact source: output.outputFile, classifier: output.name

is the reason why my artifacts were named e.g. com/mylib/mylib/0.1.1/mylib-0.1.1-prod-release.aar. Somehow it cannot be recognised when loading dependencies from maven. Changing this line to:

artifact source: output.outputFile, classifier: null

makes the file look like this com/mylib/mylib/0.1.1/mylib-0.1.1.aar which is fine apparently.

I have no idea why the first style of naming doesn't work, I assume that there is a setting which would propagate it to the meta-data. There's still bounty on this question so maybe someone can work this mystery out?

Tortile