[Android-tools-devel] Android Gradle Plugin

[殷啟聰]

Hi Markus and Hans,

Although I hope that all AOSP packages should follow the same versioning scheme
since they have different versions everywhere and they do not version so many
components, turns out that platform/tools/buildSrc doesn't have tags like
"android-6.0.0_r26", which makes things tricky.

So I propose that all AOSP packages in platform/tools/* follow the versioning
scheme of "studio-1.5" or "gradle-1.3.1", as they exist in all platform/tools/*
repositories. But should we follow "studio-*" or "gradle-*"?

AFAIK, "studio-1.5" means Android Studios 1.5, while "gradle-1.3.1" means Gradle
Plugin 1.3.1. But as I have observed, "project.ext.buildVersion" in
"base/version.gradle", which is used as the version of both projects, is exactly
the version number. So I guess the Gradle Plugin and Android Studios share the
same version. Markus, have you got any confirmation on this?

If they really share the same version, we can simply checkout the latest tags
like "{gradle,studio}-*" when getting a new upstream release.

Cheers,
Kai-Chung Yan

2016-02-09 4:43 GMT+08:00 Hans-Christoph Steiner <hans at at.or.at>:
>
>
> Markus Koschany:
>> Hi,
>>
>> I'm subscribed to android-tools-devel.
>>
>> Am 08.02.2016 um 14:22 schrieb 殷啟聰:
>>> Hi Markus,
>>>
>>> Thank you for the effort on the Java part of Android SDK!
>>>
>>> I would insist that the package should follow the naming and
>>> versioning conventions of the existing AOSP packages by Android-Tools
>>> team. For this source package, the name should be
>>> "android-platform-tools-base" and the version should be something like
>>> "6.0.0+r26-1".
>>
>> Ok, I will rename the source package to android-platform-tools-base. I'm
>> not so sure with the versioning. I have checked out the studio-1.5 tag.
>> The build system uses
>>
>> rootProject.ext.buildVersion = 1.5.0 (Android Studio version)
>> rootProject.ext.baseVersion = 24.5.0 (=> API)
>>
>> The 6.0.0+r26-1 numbers seems to be more like an internal versioning
>> scheme. In my opinion we should either use the Android Studio release
>> numbers or the API version which would be in line with the official
>> releases from:
>>
>> https://developer.android.com/sdk/index.html#Other
>>
>> or the developers guide from
>>
>> https://sites.google.com/a/android.com/tools/build
>>
>> I would go with 1.5.0 in this case.
>
> The versions/tags in the Android sources are painful.  There are many
> different ones, and its not clearly documented.  I think you are correct
> that the studio-1.5 tag is the one used for the core gradle plugin
> stuff.  The open question is whether that studio-1.5 tag is available in
> all of the git repos related to these packages.  That's why we ended up
> going with the Android OS version tag (e.g. 6.0.0_r26): because it is in
> all of the git repos, and it lines up to the various releases.
>
> In case you haven't seen it, this is worth a quick read, or please add
> anything you think should be there:
> https://wiki.debian.org/AndroidTools#Android.27s_upstream_version_names
>
>
>>> We have a simple and unified way to fetch the upstream tarball. Please
>>> check out one of our packages, e.g. src:android-platform-libcore [1].
>>
>> Thanks.
>>
>>>
>>> AFAIK this repository needs a buildSrc from [2] to build. Did you also
>>> include this part into the upstream tarball? For now we have been
>>> making one package for exactly one repository instead of merging
>>> multiple repositories. Hence if I were you I would make another source
>>> package called "android-platfrom-tools-buildsrc" which produces
>>> "android-platform-tools-buildsrc-source" containing the Java codes or
>>> "libandroid-tools-buildsrc-java" containing the "buildSrc.jar".
>>
>> I didn't need to package this repository but thanks for pointing it out
>> to me. In fact I only need build.gradle and settings.gradle from this
>> repo. I could create src:android-platform-tools-buildsrc and install the
>> gradle build files for instance into
>> /usr/share/android/android-platform-tools-buildsrc. I would still need
>> to copy these files into the build tree because they need some patches.
>>
>>>
>>> And I am also wondering where are you going to maintain this package?
>>> pkg-java or Android-Tools team?
>>
>> I think it makes sense to maintain all android-* packages as part of the
>> android-tools team and all generic packages like intellij-annotations,
>> that are useful across different packaging teams, in pkg-java.
>
> Sounds good to me.
>
> .hc
>
> _______________________________________________
> Android-tools-devel mailing list
> Android-tools-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel



-- 
/*
* 殷啟聰 | Kai-Chung Yan
* 一生只向真理與妻子低頭
* Undergraduate student in National Taichung University of Education
* LinkedIn: <https://linkedin.com/in/seamlik>
* Blog: <http://seamlik.logdown.com>
*/