0

So, I managed to create an Android library component and publish it on Maven Central. But when I'm trying to use it as a dependency in a new project, Android Studio can't seem to find the classes.

build.gradle for the app module:

repositories {
    mavenCentral()
}

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.android.support:appcompat-v7:21.0.3'
    compile 'no.hyper:libdateintervalpicker:1.0.0' //this is the one I want to use
}

This part seems to work, at least I get no sync errors. However, when trying to access to package and classes from my MainActivity, Android Studio can't find them and gives me "cannot resolve symbol" message.

I have tried downloading the classes.jar from the archive directly from Maven Central, and they are indeed in the package.

Other dependencies seem to appear in the /build/intermediates/exploded-aar folder after syncing, but that does not happen to my library.

I use Android Studio 1.0.2 on OSX 10.9.5 (Mavericks)

Any suggestions?

SirMarino
  • 526
  • 3
  • 8

2 Answers2

0

Looking in your pom, it states <packaging>aar.asc</packaging>. It should be aar instead.

JBaruch
  • 22,610
  • 5
  • 62
  • 90
  • BTW, why you got yourself into all this suffering with Maven Central when you could just use Bintray jcenter? – JBaruch Feb 04 '15 at 13:21
  • Because until a a couple of hours ago, I thought Maven Central was the place to go, but I'll look into jCenter now as well. – SirMarino Feb 04 '15 at 14:31
  • Cool :) Did my solution help? Re jcenter, also take a look [here](http://blog.bintray.com/2014/02/11/bintray-as-pain-free-gateway-to-maven-central/), you can easily have both. – JBaruch Feb 04 '15 at 14:41
  • Well, your solution put me on a track that led me to [this thread](http://stackoverflow.com/questions/27983482/library-uploaded-but-gradle-download-only-pom-and-aar-asc-from-maven-central), which seems to be the same issue, and I also found others indicating that this is either Android Studio or Maven Central/Sonatype messing things up in the process. – SirMarino Feb 04 '15 at 14:58
0

Oh, and the answer to actually being able to use the library, was to add @aar to the dependency so that it now reads

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.android.support:appcompat-v7:21.0.3'
    compile 'no.hyper:libdateintervalpicker:1.0.0@aar' //note the magic @aar
}

Edit: Removing the block

configurations {
    archives {
        extendsFrom configurations.default
    }
}

makes Gradle generate the pom with the correct packaging entry, and thus makes it possible to reference the dependency without the @aar suffix

SirMarino
  • 526
  • 3
  • 8
  • That's not a solution, that's a workaround. If you don't add the type, Gradle will try to fetch the type, mentioned in the `pom.xml`, which is incorrect (see my answer). You can force Gradle to ignore the type in the pom by explicitly adding it, as you did, but the real solution will be fixing the pom. – JBaruch Feb 07 '15 at 21:45
  • Well, then the question is "why?". I haven't actually touched the pom, but I have specified "packaging 'aar'" my pom.project block in build.gradle. I guess that means that the gradle packaging system is broken, then? – SirMarino Feb 09 '15 at 12:24
  • Hm. You specify `aar` and it generates `aar.asc` in the generated `pom.xml`? Are you positive? If so, it's a bug in Gradle. Probably you should report it and use the workaround until it is fixed. – JBaruch Feb 09 '15 at 14:05
  • Yes, I'm positive, it does look like a bug i Gradle. See my edited answer for another solution/workaround. – SirMarino Feb 13 '15 at 08:06