Uploading apk to repository

[Manfred Moser]

Hi!

I am playing with the repo sample and have added this 

uploadArchives {

    repositories {

        mavenDeployer {

           repository(url: "http://localhost:8081/nexus/content/repositories/releases") {

                 authentication(userName: "admin", password: "admin123")

             }

        }

    }

}

to get the projects uploaded to the repo with

gradle upload

That works fine for the util, baseLibrary and library parts but not for the app one.

E.g. for the baseLibrary I get

Uploading: com/example/android/multiproject/lib/1.0/lib-1.0.aar to repository remote at http://localhost:8081/nexus/content/repositories/releases

so it is uploaded as an aar. 

However the dependency in the app is not declaring the aar package format. Why is that not the case? Will it load the pom and look at the packaging automatically? Would it be okay to add the packaging to the dependency declaration just to make it a bit more clear that this dependency is an aar and not a plain jar? 

Imho this 

compile group: "com.example.android.multiproject", name: "lib", version: "1.0", ext: "aar"

should work but it actually does not where as 

compile 'com.example.android.multiproject:lib:1.0'

works.. is this on purpose or a bug? 

Now when I run gradle upload in the app I would expect it to upload the apk to the remote repository but instead I get this error message.

gradle upload

The TaskContainer.add() method has been deprecated and is scheduled to be removed in Gradle 2.0. Please use the create() method instead.

:uploadArchives

[ant:null] Error reading settings file '/private/var/folders/4_/mq34pzmj5yd7rff0wgy61y100000gn/T/gradle_empty_settings4124232035771804663.xml' - ignoring. Error was: /private/var/folders/4_/mq34pzmj5yd7rff0wgy61y100000gn/T/gradle_empty_settings4124232035771804663.xml (No such file or directory)

BUILD SUCCESSFUL

Total time: 9.148 secs

What am I doing wrong? 

manfred

[Xavier Ducrohet]

I don't know how gradle handles the packaging for dependencies. I'll check.

I don't think the app plugin add the apk as a publishable artifact. We can certainly do that.

We would need to provide some control over the groupId/artifactId and classifier.

For instance in the cae of a multi-apk for ABIs we'd probably want the classifier to be the ABI.

I'm wondering if we can define some default based on the package name, variant name, etc...

--
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!

[Manfred Moser]

Normally you would use something like this 

group = 'com.example.android.multiproject'

archivesBaseName = 'app'

version = '1.0'

and I think archivesBaseName is optional. Default would be the folder name of the project.

You could do something like combining flavor and build type into a classifier and then deploy with the classifier by default .. but make it configurable somehow.

Just a thought - it would certainly be nice imho. The repo manager could then be used e.g. for QA to pick it up from and so on.. and the releases would always be available. 

For the android maven plugin I typically configure to also upload the proguard mapping file so it is always available and does not get lost. Very handy.. 

manfred

[Xavier Ducrohet]

yeah I definitively want it to be configurable per flavor/buildtype etc... but provide some way to manage it when you have a lot of variants.

Good idea on the proguard stuff.

[Xavier Ducrohet]

What classifier/extension do you use for the mapping file? We should just use the same.

[Manfred Moser]

Its configured by the individual user.. but here is the sample that servers as example.. 

https://github.com/jayway/maven-android-plugin-samples/blob/master/morseflash/morseflash-app/pom.xml

See this snippet.

<artifact>
<file>${project.build.directory}/proguard/mapping.txt</file>
<type>map</type>
<classifier>release</classifier>
</artifact>

So the file in the repo will be named 

artifactId-version-classifer.map

so for that project it could be 

morseflash-app-1.0-release.map

But again... that is just an example. There is no standard so you could just define one.

manfred

[Xavier Ducrohet]

I talked with a Gradle dev who told me that using 

compile group: "com.example.android.multiproject", name: "lib", version: "1.0", ext: "aar"

is indeed broken. It takes this artifact only but not the dependency. It seems like fixing it is an issue since it would change the behavior.

There's another way to declare this that works but the DSL is broken (it require more data that it needs), so we'll have to wait for a fix.

In any case it's on their list of things to fix.

[Manfred Moser]

On Thu, Jun 20, 2013 at 6:09 PM, Xavier Ducrohet <x...@android.com> wrote:

I talked with a Gradle dev who told me that using 

compile group: "com.example.android.multiproject", name: "lib", version: "1.0", ext: "aar"

 

is indeed broken. It takes this artifact only but not the dependency. It seems like fixing it is an issue since it would change the behavior.

In my experience it did not even take the artifact, but just failed saying it cant find it. I am not sure how it would change behaviour since e.g. 

compile group: "com.example.android.multiproject", name: "lib", version: "1.0", ext: "jar"

works just fine (assuming it is a jar). 

 

There's another way to declare this that works but the DSL is broken (it require more data that it needs), so we'll have to wait for a fix.

In any case it's on their list of things to fix.

Great, I look forward to 0.4.3 of the plugin or Gradle 1.7 or whenever it becomes available

manfred