a76804ead4cd2ad7b382b329a2a2c19c599a7038
wiki/info/landscape/building-and-deploying.md
| ... | ... | @@ -99,19 +99,14 @@ As a result of handling the request, Final Assembly will trigger builds on [http |
| 99 | 99 | |
| 100 | 100 | We currently release the Android apps off a branch called ``android-xmake-release`` and referred to in the sequel as the "Android release branch." |
| 101 | 101 | |
| 102 | -The Android release branch holds the changes required to run a successful Android build in xMake. This cannot be overestimated, and credits go to Steffen Schaefer for pulling this off! Check out the specificities for the Android build in the top-level ``pom.xml`` file and you see why this was such a great achievement. |
|
| 103 | - |
|
| 104 | -We have various branches on which Android mobile app features are being developed. Ultimately, they should be merged into the ``master`` branch from where they get merged into the Android release branch. A so-called "Customer release" build can be triggered for the Android release branch on a [central Jenkins instance](https://xmake-mobile-dev.wdf.sap.corp/job/sapsailingprogram/job/sapsailingcapture.android-OD-dockerrun/). However, it is important to know that the xMake build profile will make sure that the version specified in the ``pom.xml`` descriptors matches in its major and minor version with a ``rel-x.y`` branch name in the central git repository at ``git.wdf.sap.corp``. For example, if the ``pom.xml`` files specify a ``1.4.0`` version, the commit to be built needs to be contained in a branch called ``rel-1.4``. |
|
| 105 | - |
|
| 106 | -Also note that once released to Nexus, the next release build will have to use at least an incremented micro version, such as 1.4.1. In order to change all versions in all `MANIFEST.MF` and `pom.xml` files consistently, the Tycho `set-version` plugin can be used. For this, the `<parent>` definition in the top-level `pom.xml` file needs to be commented out, which points to `com.sap.ldi/ldi-parent/8.0.0` or else you will get error messages that this component cannot be found (it is only found when the build is run on a central Jenkins instance that sees the Nexus repository at the right place). Then, you would have to issue the following command, setting the version number as required: |
|
| 107 | - |
|
| 102 | +The Android release branch holds the changes required to run a successful Android build in xMake. The actual build is still the Gradle build that xMake invokes like this: |
|
| 108 | 103 | ``` |
| 109 | - mvn -Dtycho.mode=maven org.eclipse.tycho:tycho-versions-plugin:set-version -DnewVersion=x.y.z |
|
| 104 | +./gradlew -Pxmake -Pversion=1.4.116 -PcommonRepoURL=https://int.repositories.cloud.sap/artifactory/build-releases/ |
|
| 110 | 105 | ``` |
| 111 | 106 | |
| 112 | -Make sure to replace `x.y.z` by the version to which you want to set your files. Then remember to uncomment the `<parent>` specification again. |
|
| 107 | +We have various branches on which Android mobile app features are being developed. Ultimately, they should be merged into the ``master`` branch from where they get merged into the Android release branch. A so-called "Customer release" build can be triggered for the Android release branch on a [central Jenkins instance](https://xmake-mobile-dev.wdf.sap.corp/job/sapsailingprogram/job/sapsailingcapture.android-SP-REL-common_directshipment/). To get a release build staged for releasing, the version numbers in a few descriptor files, particularly the ``gradle.properties`` files of each app sub-directory under ``/mobile``, as well as ``cfg/files2sign.json`` need to be adjusted to the new version. |
|
| 113 | 108 | |
| 114 | -Next, make sure to upgrade the versions in the `AndroidManifest.xml` files of the three apps we're currently shipping. The `android:versionCode` specifier is relevant for the PlayStore pushing the update to the users. The `android:versionName` is just a symbolic name which users will see (other than the `android:versionCode` which is not usually displayed to users). For the `android:versionName` we try to use a reasonable versioning scheme that should be independent of our internal rel-x.y numbering and the sequential, technical versionCode. Example: 1.1. |
|
| 109 | +Also note that once released to Nexus / Artifactory, the next release build will have to use at least an incremented micro version, such as 1.4.1. |
|
| 115 | 110 | |
| 116 | 111 | In order to get the Android release branch merged into the ``rel-x.y`` branch, the same process as explained above for the merge of iOS branches into ``fa/rel-x.y`` is required. In particular, this means that a Java Correction Workbench Correction Request [needs to be created](https://css.wdf.sap.corp/sap/bc/bsp/spn/jcwb/default.htm?newCMForProject=sapsailingcapture&newCMComponentName=SV-COE-MSO-CDP) and the latest commit to be pushed to ``refs/for/rel-x.y`` needs to be amended so that it contains a valid ``Change-Id:`` and ``CR-Id:`` line. Then, the commit needs to be voted on. Other than for the MiOS branches under ``fa/rel-x.y`` it seems to be required that _another_ committer votes with +2 to enable a merge. Once this has been done, the blue ``Submit`` button will appear on your change page (something like [https://git.wdf.sap.corp/#/c/1436212/](https://git.wdf.sap.corp/#/c/1436212/)) that you can use to technically get the commit merged into the ``rel-x.y`` branch. |
| 117 | 112 |
wiki/info/mobile/android-and-release-build.md
| ... | ... | @@ -4,13 +4,27 @@ |
| 4 | 4 | |
| 5 | 5 | ## Basic setup of the Android apps build |
| 6 | 6 | |
| 7 | -The Android Build is based on Maven and is part of the overall multi-module-build. The Android specific projects are hosted in /mobile. The build of the app projects is completely separated from Tycho/p2. |
|
| 7 | +The Android Build is based on Gradle and is separate of the overall multi-module-build. The Android specific projects are hosted in /mobile. The build of the app projects is completely separated from Tycho/p2. |
|
| 8 | + |
|
| 9 | +To build the Android apps, go to the root of the Git workspace and enter the command |
|
| 10 | +``` |
|
| 11 | + ./gradlew |
|
| 12 | +``` |
|
| 13 | +It will produce the APK files in the following locations: |
|
| 14 | +``` |
|
| 15 | +./mobile/com.sap.sailing.racecommittee.app/build/outputs/apk/release/com.sap.sailing.racecommittee.app-unsigned.apk |
|
| 16 | +./mobile/com.sap.sailing.android.buoy.positioning.app/build/outputs/apk/release/com.sap.sailing.android.buoy.positioning.app-unsigned.apk |
|
| 17 | +./mobile/com.sap.sailing.android.tracking.app/build/outputs/apk/release/com.sap.sailing.android.tracking.app-unsigned.apk |
|
| 18 | +``` |
|
| 19 | +The build job also copies them to ``java/com.sap.sailing.www/apps`` from where, during the build of the ``com.sap.sailing.www`` OSGi bundle they become part of the overall delivery and can hence be downloaded conveniently for a "side-load" style installation from any of our servers' ``/apps`` URL path. |
|
| 20 | + |
|
| 21 | +If this build works without errors, it will also be part of all full product builds, as seen on [https://hudson.sapsailing.com](https://hudson.sapsailing.com). |
|
| 8 | 22 | |
| 9 | 23 | ## Backend Build vs Android Build |
| 10 | 24 | |
| 11 | 25 | Due to some incompatibilities of the Android Build with specifics of the Tycho Build, it's not possible to build the backend and Android apps in one execution. That's why there are several profiles that control, what is part of the specific build. |
| 12 | 26 | |
| 13 | -The default activation of the profiles causes the backend build to run. The relevant profiles to switch between backend and Adnroid build are: |
|
| 27 | +The default activation of the profiles causes the backend build to run. The relevant profiles to switch between backend and Android build are: |
|
| 14 | 28 | * with-mobile (defauts to off) |
| 15 | 29 | * with-not-android-relevant (defauts to on) |
| 16 | 30 |