Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
gildegoma opened this issue Jun 28, 2014 · 2 comments

Comments

@gildegoma
Copy link

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: gildegoma/chef-android-sdk#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
Copy link
Member

mosabua commented Jun 29, 2014

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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants