Add support for Android's archivesBaseName property

[steurt]

Problem

In Android projects I like to include the version name in the resulting artifacts (e.g. android-1.0.0-release.aar instead of android-release.aar). Android supports setting a different archive name using the archivesBaseName property (Android Gradle Pluggin support).

setProperty("archivesBaseName", "${project.name}-$versionName")

So Android properly supports this, but the novoda bintray-release plugin doesn't. It always uses the project.name for the artifact name. So changing the archivesBaseName will cause the bintray-release upload to fail, since it can't find the artifact to upload.

> Failed to publish publication 'release' to repository 'mavenLocal'
   > Invalid publication 'release': artifact file does not exist: '/Users/myuser/mybuilddir/outputs/aar/android-release.aar'

Solution

I've modified the AndroidArtifacts.groovy to use the archivesBaseName property so it will always look for the correct artifact name. Whether it's modified or default: it's value is always set.

I've also modified the build.gradle of the android samples project to demonstrate it's usage. Running a release for the android sample project also shows it works as desired.

Update

It would be great if the (awesome 😎) novoda bintray-release plugin can support this! I hope you'll like this PR, include it in bintray-release and release it in an update soon so I can really start using it.

Any feedback is appreciated!

[hal9002]

Can one of the admins review this PR?

[takecare]

what about checking if archivesBaseName is defined, if so use it, if not fall back to ${project.name}-${variant.baseName}?

[steurt]

Sure it can be added as a fallback, but I would prefer not to. This seems like the only right way to determine the archive's name.

Do you agree, or would you like me to add the fallback anyway?

I do agree with you. Since it's a dynamic property and not an an actual property of the Project type it's probably better to have a fallback. I'll add this!

[StefMa]

Since it's an undocumented API I would not merge that at all.
But as the past shows we can more or less trust them I've fine with that fallback implementation 👍

[takecare]

ok to test

[StefMa]

Feel free to merge @takecare

[steurt]

@takecare or @StefMa any idea when I can expect an update of the plugin?

[mr-archano]

@steurt I am taking a look at the changelog right now, I am gonna roll a new release shortly after. Expect 0.8.1 to hit JCenter later today. (I will ping you here).

Thanks everyone for the patience, we are trying to improve the support on our side to speed up this kind of things in the future.