Not including external dependencies in generated .aar for library project

[Traun Leyden]

I have a library module inside of a project, and when I declare external dependencies the generated .aar under build/libs does _not_ have these libraries included as I would expect.  (seems like a bug)

Here is my build.gradle:

...

apply plugin: 'android-library'

repositories {

    mavenCentral()

}

dependencies {

    compile files('libs/android-support-v4.jar')

    compile 'org.codehaus.jackson:jackson-core-asl:1.9.2'

    compile 'org.codehaus.jackson:jackson-mapper-asl:1.9.2'

}

...

I decided to try adding these dependencies a different way, to compare behavior.

Modified build.gradle:

...

apply plugin: 'android-library'

repositories {

    mavenCentral()

}

dependencies {

    compile files('libs/android-support-v4.jar', 'libs/jackson-core-asl-1.9.2.jar', 'libs/jackson-mapper-asl-1.9.2.jar')

}

...

and doing it this way works -- when I unzip the .aar, I do see those libraries included:

$ unzip CBLite.zip

Archive:  CBLite.zip

  inflating: AndroidManifest.xml

  inflating: classes.jar

  inflating: R.txt

  inflating: libs/android-support-v4.jar

  inflating: libs/jackson-core-asl-1.9.2.jar  

  inflating: libs/jackson-mapper-asl-1.9.2.jar

  ... etc

which is the expected/desired behavior.

Does this look like a bug?  Or am I doing something wrong?  

Btw I'm using the latest version of android studio and gradle plugin 0.4, and I'm building via "./gradlew build" in the top level project.

[Patrick Boos]

I had a similar problem yesterday when using Android Studio. Building in Android Studio did not include it. Running gradle assemble included it correctly. After running it on the command line, even Android Studio added it. Very confusing.

[Xavier Ducrohet]

This is normal and expected.

Using an artifact will *not* include it in the aar. The whole point of using remote artifacts is to not rely on jars but instead on the artifact adress so that the project using your 'aa'r can resolve all its dependency graph, find duplicates, resolve conflicts, etc...

If you publish your 'aar' on Maven, the artifact POM will contain the dependencies. If you use it from a multi-project setup, the project generating the 'aar' will send those dependencies to projects referencing it.

For local jars, because those are no ways of knowing what the jar file is we have to package it locally, but this is really not something you should use if you are going to submit the 'aar' to an artifact repo.

--
You received this message because you are subscribed to the Google Groups "adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Xavier Ducrohet
Android SDK Tech Lead
Google Inc.
http://developer.android.com | http://tools.android.com

Please do not send me questions directly. Thanks!

[Traun Leyden]

Thanks, that makes perfect sense.  I have a follow-up question on why my tests were getting NoClassDefErrors when trying to call code in remote dependencies, but I'll post that later after digging into it a little further (I'd assumed it was because the remote dependency jars never made it to the .aar).

But on the topic of publishing .aar's to Maven, the only mention of this that I've seen in the docs is this:

Current limitations of milestone 3 (version 0.3)

Binary packaging of library is still going through changes. Do not upload libraries to maven central (or other similar repos) just yet.

Is that still the case, or has it been implemented in 0.4?  If so, how can it be done?  

[Xavier Ducrohet]

yes you can upload to repositories. It's done the same way you upload any Gradle project to a repositories. There's some documentation about it on gradle.org.

[Xavier Ducrohet]

Note that "install" is not a regular Gradle tasks. "uploadArchives" is the normal upload task.

You can certainly create an no-action "install" task that just depends on uploadArchives but you don't really get anything from doing this.

Since the Android plugin also uses "install*" to install APKs on devices, so this might get more confusing.

On Fri, May 24, 2013 at 8:17 AM, Alberto Alonso Ruibal <alberto...@gmail.com> wrote:

About uploading android library projects to the local maven repository: "gradle install" does not work as expected, so I use a little hack in build.gradle to make it work:

apply plugin: 'maven'

uploadArchives {

  repositories {

    mavenDeployer {

      repository url: 'file://' + new File(System.getProperty('user.home'), '.m2/repository').absolutePath

    }

  }

}

task install(dependsOn: uploadArchives)

[Alberto Alonso Ruibal]

"install" is a  task of the Maven plugin http://www.gradle.org/docs/current/userguide/maven_plugin.html

With not-android java libraries and a build.gradle file like:

apply plugin: 'java'

apply plugin: 'maven'

group = 'com.company'

version = '0.8'

You can do "gradle install" to copy the jar to the local maven repository (like with the old "mvn install"). Thats why I said that it doesn't "work as expected", with android libraries does not work ;)

Thx!

[Xavier Ducrohet]

Hey Alberto,

I don't recall this task being there when I setup our builds. Maybe it's been added recently. In any case, I stand corrected!

What is happening with Library Projects? I would expect Gradle to just generate the artifact and push it to the local maven repo.

[Manfred Moser]

On the android maven plugin we have name spacing for plugins which allows reuse of keywords like this

E.g. 

mvn deploy:deploy 

deploys the apk to the repository manager with the deploy plugin

mvn android:deploy 

deploys the apk to all attached devices and emulators with the android plugin.. 

Maybe something like that can be done in the gradle world too.. 

[Alberto Alonso Ruibal]

In some scenarios we don't need to push the Java library artifacts to the local maven repo, like in multi-project builds with project dependencies:

dependencies {

    compile project(':library_project')

}

Namespaces would be a great solution, but Gradle does not supports them AFAIK