clean up of android project and examples

[SierraGolf]

the generation of an apklib is not necessary and it leads to dirty workarounds when using gradle, see PR816

with this change maven deployments (install/deploy) will just install a jar-file to the respective repositories.

[brasmusson]

If the generation of the apklib is removed, then also the examples using cucumber-android (android-test, cukeulator-test), need to not declaring that dependency as an apklib.

When not generating an apklib, is there any need for the AndroidManifest.xml file?

[SierraGolf]

It seems that the examples are currently broken, at least for me. I will look into that and clean up the apklib references and the AndroidManifest.xml.

[SierraGolf]

I added the following changes:

• removed android maven plugin and related android files from cucumber-android project
• fixed broken example projects (a lot of file relocations)
• bumped android-maven-plugin version to 4.0.0

[brasmusson]

Have you actually managed to run the android-test and cukeulator-test using android-maven-plugin v4.0.0, I run into this problem? As long as cucumber-android was an apklib project, v4.0.0(-rcN) failed already on not unpacking the apklib. To actually be able or run the examples (on device or emulator), I had to downgrade to v3.9.0-rc1 (in #795, where I took the smaller change of declaring the now non-standard locations on files in examples/android/pom.xml). #795 also run the android examples on Travis before deploying the cucumber-android snapshot. Just now a merged in the removal of the apklib generation (but not the latest commits on this PR).

[SierraGolf]

Yeah, as you can see in the configuration I hacked it. Except for that small hack I was able to run everything now.

[brasmusson]

Does the android-maven-plugin need to be declared here at all? Previously v3.9.0-rc3 was declared here, but it was actually v4.0.0-rc.1 that was used, and that did not seems to make any difference.

[SierraGolf]

you are right, we don't need it here, since we only have it as a dependency in the android examples now. I will remove it.

[brasmusson]

AFAIK, the android module was put in a separate maven profile because to build it, you need to have an android-sdk installed. Now that cucumber-android is built like any other jar, the android module could be moved from the android profile to the common module. The the snapshot release of cucumber-android would be deployed together with the other module by the "non-android" oraclejdk7 job on Travis, and the "android" oraclejdk7 job could be used to build the android examples (similar to the openjdk7 job on Travis, which build the other examples).

[SierraGolf]

Sounds good to me, do you want me do amend these changes to this pull request?

[brasmusson]

When I experimented with moving the android module from a separate profile, the android job on Travis (now only executing the android examples) failed. The log contained the error Killed emulator -avd test -no-skin -no-audio -no-window, the Travis docs indicate that the process was killed due to to much resource usage. The handful times that job has run tests on the version of that emulator previously it worked. The fact that it might require some experimentation to find a stable configuration to run the android examples on Travis, could be an argument not to delay this PR until that is done.

[SierraGolf]

I think we should do the following:

1. merge this pull request, because it fixes the examples (even though there is currently no ci to proof it)
2. create a new pull request which kills the android profile and puts the android module in the "default" profile, which makes the release easier
3. create a new pull request which adds the examples to ci, which might not be possible in a reliable way since the whole android support on travis is still beta

what do you think?

[brasmusson]

I think that is a good strategy. It is definitely better to use the build in android support, rather as we do no "manually" install the android sdk on Travis.

[aslakhellesoy]

Great work on this @SierraGolf and @brasmusson. Eager to see this improve!

[SierraGolf]

So I guess I can merge this pull request now?

[aslakhellesoy]

Go for it @SierraGolf. Can you add a note in History.md to summarise the changes?

[SierraGolf]

Sure, done! Anything against also merging #820 ?

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.