search

simpligility / maven-android-sdk-deployer

A tool to install components of the Android SDK into a Maven repository or repository manager to use with the Android Maven Plugin, Gradle and other tools.
Apache License 2.0
1.39k stars 453 forks source link

Provide mapping to Android SDK identifiers to ease automated installations #236

Open gildegoma opened 10 years ago

gildegoma commented 10 years ago

Problem to solve

Automatically deploy corresponding maven artifacts when installing (or updating) a component with android update sdk command. In this context, the current Maven profile names (e.g. 4.4, 4.4W, L, etc.) are not easy to map.

See also: https://github.com/gildegoma/chef-android-sdk/issues/14

Possible Approaches

Before starting to work on a pull request for that change request, I would like to check which approach is the better. Below two propositions... but maybe you have even an easier solution.

One Maven Profile for each Android SDK component

Example:
yes | android update sdk --no-ui --all --filter addon-google_apis-google-19
mvn clean install -P addon-google_apis-google-19

in main pom.xml:

        <profile>
            <id>addon-google_apis-google-19</id>
            <modules>
                <module>add-ons</module>
            </modules>
        </profile>
...

in all intermediate submodules (e.g. add-ons/pom.xml):

        <profile>
            <id>addon-google_apis-google-19</id>
            <modules>
                <module>google-apis-19</module>
            </modules>
        </profile>
...

This approach potentially means creating lots of static maven profiles. I don't know if such approach fits with your maintenance guidelines, hence the proposition of a second approach below...

A helper shell script that knows the "translation" rules

Similarly to this mapping, maven-android-sdk-deployer could ship a little (script) tool that translate the Android SDK identifiers to corresponding maven command.

This approach should be more concise, as dynamic translation rules can be implemented. Maybe there is a way to include such kind of approach in a Maven-style workflow, but I did not take time to further investigate.

Example:
addon-google_apis-google-19 -> add-ons/google-apis-19

android-mvn-deploy addon-google_apis-google-19 -> mvn install -pl add-ons/google-apis-19

Components available in Android SDK 23

Some components like sample-... should not be considered, but I put here the complete list of identifiers to better illustrate the need for this trivial mapping.

tools
platform-tools
build-tools-20.0.0
build-tools-19.1.0
build-tools-19.0.3
build-tools-19.0.2
build-tools-19.0.1
build-tools-19.0.0
build-tools-18.1.1
build-tools-18.1.0
build-tools-18.0.1
build-tools-17.0.0
doc-L
android-20
android-L
android-19
android-18
android-17
android-16
android-15
android-14
android-13
android-12
android-11
android-10
android-9
android-8
android-7
android-6
android-5
android-4
android-3
android-2
sample-20
sample-L
sample-19
sample-18
sample-17
sample-16
sample-15
sample-14
sample-13
sample-12
sample-11
sample-10
sample-9
sample-8
sample-7
sys-img-armeabi-v7a-android-wear-20
sys-img-x86-android-wear-20
sys-img-armeabi-v7a-android-tv-l
sys-img-x86-android-tv-l
sys-img-armeabi-v7a-android-l
sys-img-x86-android-l
sys-img-armeabi-v7a-android-19
sys-img-x86-android-19
sys-img-armeabi-v7a-android-18
sys-img-x86-android-18
sys-img-armeabi-v7a-android-17
sys-img-x86-android-17
sys-img-mips-android-17
sys-img-armeabi-v7a-android-16
sys-img-x86-android-16
sys-img-mips-android-16
sys-img-armeabi-v7a-android-15
sys-img-x86-android-15
sys-img-mips-android-15
sys-img-armeabi-v7a-android-14
sys-img-x86-android-10
addon-google_apis_x86-google-19
addon-google_apis-google-19
addon-google_gdk-google-19
addon-google_apis-google-18
addon-google_apis-google-17
addon-google_apis-google-16
addon-google_apis-google-15
addon-google_apis-google-14
addon-google_apis-google-13
addon-google_tv_addon-google-13
addon-google_apis-google-12
addon-google_tv_addon-google-12
addon-google_apis-google-11
addon-google_apis-google-10
addon-google_apis-google-9
addon-google_apis-google-8
addon-google_apis-google-7
addon-google_apis-google-6
addon-google_apis-google-5
addon-google_apis-google-4
addon-google_apis-google-3
source-20
source-19
source-18
source-17
source-16
source-15
source-14
extra-android-m2repository
extra-android-support
extra-google-admob_ads_sdk
extra-google-analytics_sdk_v2
extra-google-gcm
extra-google-google_play_services_froyo
extra-google-google_play_services
extra-google-m2repository
extra-google-play_apk_expansion
extra-google-play_billing
extra-google-play_licensing
extra-google-webdriver

list obtained with android list sdk --no-ui --all --extended | grep -E '^id:' | awk -F '"' '{$1=""; print $2}'

mosabua commented 10 years ago

I dont like the idea of lots of profiles. Maybe we can have something like a set of command that need to be executed for each component. Problem is that this gets complicated with more than one component or lots of runs will be repeats. Not sure what the best solution would be at this stage.

gildegoma commented 10 years ago

Yep, the "One Maven Profile for each Android SDK" approach is quite heavy and redundant. I suspected that you won't like/accept it, but preferred to ask for double check.

Shipping (and maintaining) a "translator" script similar to https://github.com/ruleant/chef-android-sdk/blob/41db526612921586bbfcc93dbcd78202febc8894/recipes/maven-rescue.rb#L35-L47 would be enough for my needs.

More proposals? (Note that I won't work on this before August-September and help is more than welcome!)