Changes in 6a41186: Updated building and deploying (markdown)

				wiki/info/landscape/building-and-deploying.md
			
          @@ -93,9 +93,9 @@ When the test build was successful, the branch contents need to be merged into t

              <pre>gitdir=$(git rev-parse --git-dir); scp -p -P 29418 d000000@git.wdf.sap.corp:hooks/commit-msg ${gitdir}/hooks/</pre>

          -The ``CR-Id:`` is more tricky. It is produced by the Java Correction Workbench where a Correction Request needs to be created. This can be achieved using [this link](https://css.wdf.sap.corp/sap/bc/bsp/spn/jcwb/default.htm?newCMForProject=sapsailingcapture&newCMComponentName=SV-COE-MSO-CDP) which is also contained in the lower left corner of our [Project Portal Page](https://projectportal.neo.ondemand.com/projects/sapsailingcapture). The correction request shall describe what has been corrected. In our project's context it seems useful to link the correction we're trying to release to a bug in our Bugzilla. For this, select "External" as the "Issue Type" and enter the bug's URL as well as a short text. The "ACH Component" should have been pre-filled and should read ``SV-COE-MSO-CDP``. If not, make sure you enter the text ``SV-COE-MSO-CDP`` and wait for the tool to complete this to "CashDesk Plus" before you press "Next". Ultimately, you will see a Correction Request now in the Java Correction Workbench and you should be able to copy its technical ID to use for the ``CR-Id:`` commit tag. If you hover the mouse over the correction request's ID, a small "copy" button will appear, easing your life.

          +The ``CR-Id:`` is more tricky. For Android at least it seems it may no longer be needed, so you could theoretically use anything for the CR-Id: value. It is produced by the Java Correction Workbench where a Correction Request needs to be created. This can be achieved using [this link](https://css.wdf.sap.corp/sap/bc/bsp/spn/jcwb/default.htm?newCMForProject=sapsailingcapture&newCMComponentName=SV-COE-MSO-CDP) which is also contained in the lower left corner of our [Project Portal Page](https://projectportal.neo.ondemand.com/projects/sapsailingcapture). The correction request shall describe what has been corrected. In our project's context it seems useful to link the correction we're trying to release to a bug in our Bugzilla. For this, select "External" as the "Issue Type" and enter the bug's URL as well as a short text. The "ACH Component" should have been pre-filled and should read ``SV-COE-MSO-CDP``. If not, make sure you enter the text ``SV-COE-MSO-CDP`` and wait for the tool to complete this to "CashDesk Plus" before you press "Next". Ultimately, you will see a Correction Request now in the Java Correction Workbench and you should be able to copy its technical ID to use for the ``CR-Id:`` commit tag. If you hover the mouse over the correction request's ID, a small "copy" button will appear, easing your life.

          -Once you have the Correction Request's ID, you need to amend your latest commit that shall be pushed onto fa/rel-1.x:

          +Once you have (for the Android case maybe "invented") the Correction Request's ID, you need to amend your latest commit that shall be pushed onto fa/rel-1.x:

              <pre>git commit --amend</pre>

          @@ -135,8 +135,12 @@ Many of the above steps can be automated by using the script ``configuration/rel

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

           ```

          +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.

          -Once this is done, a [Customer release build can be started](https://xmake-ldi.wdf.sap.corp:8443/view/SAPSail/job/sapsailingcapture-Release/). Select ``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 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.

          +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).

          +

          +Once this is done, a [Customer release build can be started](https://xmake-ldi.wdf.sap.corp:8443/view/SAPSail/job/sapsailingcapture-Release/). 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.

           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

...	...	@@ -93,9 +93,9 @@ When the test build was successful, the branch contents need to be merged into t
93	93
94	94	<pre>gitdir=$(git rev-parse --git-dir); scp -p -P 29418 d000000@git.wdf.sap.corp:hooks/commit-msg ${gitdir}/hooks/</pre>
95	95
96		-The ``CR-Id:`` is more tricky. It is produced by the Java Correction Workbench where a Correction Request needs to be created. This can be achieved using [this link](https://css.wdf.sap.corp/sap/bc/bsp/spn/jcwb/default.htm?newCMForProject=sapsailingcapture&newCMComponentName=SV-COE-MSO-CDP) which is also contained in the lower left corner of our [Project Portal Page](https://projectportal.neo.ondemand.com/projects/sapsailingcapture). The correction request shall describe what has been corrected. In our project's context it seems useful to link the correction we're trying to release to a bug in our Bugzilla. For this, select "External" as the "Issue Type" and enter the bug's URL as well as a short text. The "ACH Component" should have been pre-filled and should read ``SV-COE-MSO-CDP``. If not, make sure you enter the text ``SV-COE-MSO-CDP`` and wait for the tool to complete this to "CashDesk Plus" before you press "Next". Ultimately, you will see a Correction Request now in the Java Correction Workbench and you should be able to copy its technical ID to use for the ``CR-Id:`` commit tag. If you hover the mouse over the correction request's ID, a small "copy" button will appear, easing your life.
	96	+The ``CR-Id:`` is more tricky. For Android at least it seems it may no longer be needed, so you could theoretically use anything for the CR-Id: value. It is produced by the Java Correction Workbench where a Correction Request needs to be created. This can be achieved using [this link](https://css.wdf.sap.corp/sap/bc/bsp/spn/jcwb/default.htm?newCMForProject=sapsailingcapture&newCMComponentName=SV-COE-MSO-CDP) which is also contained in the lower left corner of our [Project Portal Page](https://projectportal.neo.ondemand.com/projects/sapsailingcapture). The correction request shall describe what has been corrected. In our project's context it seems useful to link the correction we're trying to release to a bug in our Bugzilla. For this, select "External" as the "Issue Type" and enter the bug's URL as well as a short text. The "ACH Component" should have been pre-filled and should read ``SV-COE-MSO-CDP``. If not, make sure you enter the text ``SV-COE-MSO-CDP`` and wait for the tool to complete this to "CashDesk Plus" before you press "Next". Ultimately, you will see a Correction Request now in the Java Correction Workbench and you should be able to copy its technical ID to use for the ``CR-Id:`` commit tag. If you hover the mouse over the correction request's ID, a small "copy" button will appear, easing your life.
97	97
98		-Once you have the Correction Request's ID, you need to amend your latest commit that shall be pushed onto fa/rel-1.x:
	98	+Once you have (for the Android case maybe "invented") the Correction Request's ID, you need to amend your latest commit that shall be pushed onto fa/rel-1.x:
99	99
100	100	<pre>git commit --amend</pre>
101	101
...	...	@@ -135,8 +135,12 @@ Many of the above steps can be automated by using the script ``configuration/rel
135	135	./configuration/releaseAndroidApps.sh CR-Id: 012003146900000486712016
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	+
138	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.
139	141
140		-Once this is done, a [Customer release build can be started](https://xmake-ldi.wdf.sap.corp:8443/view/SAPSail/job/sapsailingcapture-Release/). Select ``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 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.
	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).
	143	+
	144	+Once this is done, a [Customer release build can be started](https://xmake-ldi.wdf.sap.corp:8443/view/SAPSail/job/sapsailingcapture-Release/). 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.
141	145
142	146	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