Changes in a34f43a: Updated building and deploying (markdown)

				wiki/info/landscape/building-and-deploying.md
			
          @@ -129,18 +129,21 @@ Next, make sure to upgrade the versions in the `AndroidManifest.xml` files of th

           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.

          -Many of the above steps can be automated by using the script ``configuration/releaseAndroidApps.sh``. It accepts the Java Correction Workbench-issued Correction Request ID tag, ready for appending to the git commit message. Call like this:

          +Many of the above steps can be automated by using the script ``configuration/releaseAndroidApps.sh``. Call like this:

           ```

          -        ./configuration/releaseAndroidApps.sh CR-Id: 012003146900000486712016

          +        ./configuration/releaseAndroidApps.sh

           ```

          -Note again that for Android the CR-Id: does not really seem to be required anymore. You may make one up...

          -

          -This will checkout the `android-xmake-release` branch, merge the `rel-1.4` release branch into it, push the result again so Gerrit knows this commit / change already. Then, the version substitutions for all `pom.xml` and `MANIFEST.MF` files are carried out automatically by looking at the version currently declared in the root `pom.xml`. If that's a `-SNAPSHOT` version, only the `-SNAPSHOT` suffix is removed to obtain the new release version number. If no `-SNAPSHOT` suffix is found, the micro version is increased by one (e.g., 1.4.18 --&gt; 1.4.19). Furthermore, the `android:versionCode` number is increased by one for each of the three apps in their `AndroidManifest.xml`, and the `android:versionName` which is assumed to have the format major.minor will have the minor version increased by one. The result is committed to git, the commit is amended using the `CR-Id` tag passed on the command line, and the resulting amended commit is pushed to the `refs/for/rel-1.4` branch for Gerrit review and approval.

          +Additional options:

          +```

          +    -m Disable upgrading the versionCode and versionName

          +    -g Disable the final git push operation to fa/rel-1.4

          +    -r The git remote; defaults to origin

          +```

          -2018-05-01: The approval process seems to have changed. While Gerrit now again wants to see a second opinion for a merge, it seems possible now to push the branch directly onto the rel-1.4 branch. (At least it worked for me after approving my commit myself which was still not automatically being merged).

          +This will checkout the `android-xmake-release` branch, merge the `f/arel-1.4` release branch into it, push the result again so Gerrit knows this commit / change already. Then, the version substitutions for all `pom.xml` and `MANIFEST.MF` files are carried out automatically by looking at the version currently declared in the root `pom.xml`. If that's a `-SNAPSHOT` version, only the `-SNAPSHOT` suffix is removed to obtain the new release version number. If no `-SNAPSHOT` suffix is found, the micro version is increased by one (e.g., 1.4.18 --&gt; 1.4.19). Furthermore, the `android:versionCode` number is increased by one for each of the three apps in their `AndroidManifest.xml`, and the `android:versionName` which is assumed to have the format major.minor will have the minor version increased by one. The result is committed to git and the resulting commit is pushed to the fa/rel-1.4 branch.

          -Once this is done, a [Customer release build can be started](https://xmake-mobile-dev.wdf.sap.corp:8443/job/sapsailingprogram/job/sapsailingcapture-SP-REL-common_directshipment/). Select "Build with Parameters" from the left, then select ``Stage`` as the build mode, then ``customer`` as the ``RELEASE_MODE`` and enter the ``rel-x.y`` branch name in the "TREEISH" field, make sure the Maven version 3.1.1 is selected, select Tycho version 1.0.0, switch the "Next development version" to ``no change`` and click the "Build" button. If the build succeeds, Final Assembly should be able to _promote_ the build artifact, such as the ``.apk`` files which should have been signed using the SAP certificate.

          +Once this is done, a [Customer release build can be started](https://xmake-mobile-dev.wdf.sap.corp:8443/job/sapsailingprogram/job/sapsailingcapture-SP-REL-common_directshipment/). Select "Build with Parameters" from the left, then select ``Stage`` as the build mode, then ``customer`` as the ``RELEASE_MODE`` and enter the ``fa/rel-x.y`` branch name in the "TREEISH" field, make sure the Maven version 3.1.1 is selected, select Tycho version 1.0.0, switch the "Next development version" to ``no change`` and click the "Build" button. If the build succeeds, Final Assembly should be able to _promote_ the build artifact, such as the ``.apk`` files which should have been signed using the SAP certificate.

           If the build fails due to missing Nexus artifacts, check out the document describing [how to upload artifacts to Nexus](https://wiki.wdf.sap.corp/wiki/display/LeanDI/Uploading+Third+Party+Artifacts+to+Nexus#UploadingThirdPartyArtifactstoNexus-1.CreateaJiraTicket). You will have to create a JIRA ticked in this process and upload the artifact and its ``pom.xml`` file to Nexus. Usually, these requests get handled within less than 48 hours. Good luck...

          \ No newline at end of file

...	...	@@ -129,18 +129,21 @@ Next, make sure to upgrade the versions in the `AndroidManifest.xml` files of th
129	129
130	130	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.
131	131
132		-Many of the above steps can be automated by using the script ``configuration/releaseAndroidApps.sh``. It accepts the Java Correction Workbench-issued Correction Request ID tag, ready for appending to the git commit message. Call like this:
	132	+Many of the above steps can be automated by using the script ``configuration/releaseAndroidApps.sh``. Call like this:
133	133
134	134	```
135		- ./configuration/releaseAndroidApps.sh CR-Id: 012003146900000486712016
	135	+ ./configuration/releaseAndroidApps.sh
136	136	```
137	137
138		-Note again that for Android the CR-Id: does not really seem to be required anymore. You may make one up...
139		-
140		-This will checkout the `android-xmake-release` branch, merge the `rel-1.4` release branch into it, push the result again so Gerrit knows this commit / change already. Then, the version substitutions for all `pom.xml` and `MANIFEST.MF` files are carried out automatically by looking at the version currently declared in the root `pom.xml`. If that's a `-SNAPSHOT` version, only the `-SNAPSHOT` suffix is removed to obtain the new release version number. If no `-SNAPSHOT` suffix is found, the micro version is increased by one (e.g., 1.4.18 --> 1.4.19). Furthermore, the `android:versionCode` number is increased by one for each of the three apps in their `AndroidManifest.xml`, and the `android:versionName` which is assumed to have the format major.minor will have the minor version increased by one. The result is committed to git, the commit is amended using the `CR-Id` tag passed on the command line, and the resulting amended commit is pushed to the `refs/for/rel-1.4` branch for Gerrit review and approval.
	138	+Additional options:
	139	+```
	140	+ -m Disable upgrading the versionCode and versionName
	141	+ -g Disable the final git push operation to fa/rel-1.4
	142	+ -r The git remote; defaults to origin
	143	+```
141	144
142		-2018-05-01: The approval process seems to have changed. While Gerrit now again wants to see a second opinion for a merge, it seems possible now to push the branch directly onto the rel-1.4 branch. (At least it worked for me after approving my commit myself which was still not automatically being merged).
	145	+This will checkout the `android-xmake-release` branch, merge the `f/arel-1.4` release branch into it, push the result again so Gerrit knows this commit / change already. Then, the version substitutions for all `pom.xml` and `MANIFEST.MF` files are carried out automatically by looking at the version currently declared in the root `pom.xml`. If that's a `-SNAPSHOT` version, only the `-SNAPSHOT` suffix is removed to obtain the new release version number. If no `-SNAPSHOT` suffix is found, the micro version is increased by one (e.g., 1.4.18 --> 1.4.19). Furthermore, the `android:versionCode` number is increased by one for each of the three apps in their `AndroidManifest.xml`, and the `android:versionName` which is assumed to have the format major.minor will have the minor version increased by one. The result is committed to git and the resulting commit is pushed to the fa/rel-1.4 branch.
143	146
144		-Once this is done, a [Customer release build can be started](https://xmake-mobile-dev.wdf.sap.corp:8443/job/sapsailingprogram/job/sapsailingcapture-SP-REL-common_directshipment/). Select "Build with Parameters" from the left, then select ``Stage`` as the build mode, then ``customer`` as the ``RELEASE_MODE`` and enter the ``rel-x.y`` branch name in the "TREEISH" field, make sure the Maven version 3.1.1 is selected, select Tycho version 1.0.0, switch the "Next development version" to ``no change`` and click the "Build" button. If the build succeeds, Final Assembly should be able to _promote_ the build artifact, such as the ``.apk`` files which should have been signed using the SAP certificate.
	147	+Once this is done, a [Customer release build can be started](https://xmake-mobile-dev.wdf.sap.corp:8443/job/sapsailingprogram/job/sapsailingcapture-SP-REL-common_directshipment/). Select "Build with Parameters" from the left, then select ``Stage`` as the build mode, then ``customer`` as the ``RELEASE_MODE`` and enter the ``fa/rel-x.y`` branch name in the "TREEISH" field, make sure the Maven version 3.1.1 is selected, select Tycho version 1.0.0, switch the "Next development version" to ``no change`` and click the "Build" button. If the build succeeds, Final Assembly should be able to _promote_ the build artifact, such as the ``.apk`` files which should have been signed using the SAP certificate.
145	148
146	149	If the build fails due to missing Nexus artifacts, check out the document describing [how to upload artifacts to Nexus](https://wiki.wdf.sap.corp/wiki/display/LeanDI/Uploading+Third+Party+Artifacts+to+Nexus#UploadingThirdPartyArtifactstoNexus-1.CreateaJiraTicket). You will have to create a JIRA ticked in this process and upload the artifact and its ``pom.xml`` file to Nexus. Usually, these requests get handled within less than 48 hours. Good luck...
...	...	\ No newline at end of file