Migration

Overview

If you have previously used the Multitarget Application Archive Builder for building your MTA projects, you should be aware of the differences between the tools.

Features that are handled differently in the Cloud MTA Build Tool

The Cloud MTA build Tool uses GNU Make technology for building an MTA project. Therefore, you should have GNU Make installed in your build environmnet.

For more information, see sections GNU Make installation and commands for building a project.
Packaging of HTML5 modules in deploy_mode=html5-repo You need to update your mta.yaml file to exclude html5 modules from the resulting MTA archive and configure the build result folder. In order to do that, add the following to the build-parameters section for each module of this type:
```
   build-parameters:
      supported-platforms: []
      build-result: dist
```
For more information about the supported-platforms build parameter, see Configuring and Packaging Modules According to Target Platforms.
The following build-parameters are not supported by the Cloud MTA Build Tool:
- npm-opts
- grunt-opt
- maven-opts
If you need to change the default build behavior defined for the corresponding builder, see configure custom builder. For a complete list of available builders and their default behaviors, see Builders execution commands. If you replace the maven builder with the custom builder, you also need to set the build-result parameter (if it was not configured explicitly) as follows:
```
- name: module1
  type: java
  build-parameters:     
     builder: custom
     ...
     build-result: target/*.war
     ...     
```
The Cloud MTA Build tool strictly validates the rule that names of modules, resources, and provided property sets, are unique within the mta.yaml file. This ensures that when the name is referenced in the requires section, it is unambiguously resolved.

The Multitarget Application Archive Builder allowed the use of the same name for a module and for one of its property sets. For example:
```
- name: SOME_NAME
    type: java
    path: srv
    provides:
      - name: SOME_NAME
        properties:
          url: ${default-url}
```
When migrating to the new build tool, you need to rename either the module or the provided property set. For example:
```
- name: SOME_NAME
    type: java
    path: srv
    provides:
      - name: SOME_NAME_API # New name
        properties:
          url: ${default-url}
```
After renaming, make sure that the places where the name is used refer to the correct artifact.
The hdb builder is not supported by the Cloud MTA Build tool. You no longer require builder settings for the hdb module because the required npm install --production command is run by default for this module type.

If you used this builder for other module types, you can repace it with the npm builder or use the custom builder that runs the "npm install --production"command.

NOTE: If you try to build the project without the changes above, the build tool will identify this and will fail the build with the corresponding errors.

The `hdb` module requires the `package.json` file in the module's folder. If your `hdb` module does not contain the file, you should manually create it with the following content:
```
{
    "name": "deploy",
    "dependencies": {
        "@sap/hdi-deploy": "^3"
    },
    "scripts": {
        "start": "node node_modules/@sap/hdi-deploy/deploy.js"
    }
}
```

NOTE: If you try to deploy an MTA archive generated without this change, the operation will fail.

Service creation or service binding parameters provided in external files and referenced by the path property of the correponding entity in the mta.yaml are packaged differently by the tools into the result MTA archive.

Therefore, if you have a JSON file with service creation parameters or service binding parameters and your JSON file contains parameters or placeholders that should be resolved when you deploy the MTA archive, the correponding properties should be moved to the mta.yaml file. Otherwise, values assigned to these properties during deployment will be incorrect, because the parameters or placeholders are resolved only if they are specified within an MTA descriptor, i.e. the mta.yaml or mtad.yaml files.

For example, if you provide parameters for creating a UAA service in an xs-security.json file:
```
resources:
  - name: my-uaa
    type: com.sap.xs.uaa
    parameters:
      path: ./xs-security.json
```
and your xs-security.json file contains a property whose value should be resolved during the MTA archive deployment:
```
{
  "xsappname": "${default-xsappname}"
}
```
then, you need to modify your mta.yaml file as follows:
```
resources:
  - name: my-uaa
    type: com.sap.xs.uaa
    parameters:
      path: ./xs-security.json
      config:
        xsappname: "${default-xsappname}"
```
In the xs-security.json file, you can assign the property a temporary value that does not use the parameter. During deployment, the value specified directly in the MTA descriptor overrides the value specified in the JSON file.
```
{
  "xsappname": "tmp_appname"
}
```
Alternatively, you can remove the property from your xs-security.json file.

NOTE: If you try to deploy the project without the changes above, the deploy service will identify this and will fail the deployment with the corresponding errors.

Migration of SAP Web IDE Full-Stack Extensions

If you have custom extensions for SAP Web IDE Full-Stack and you need to re-build them using the Cloud MTA Build Tool, for example, as part of a new version release process, you should adjust the mta.yaml file of the extension MTA project following the steps specified in the comments below:


_schema-version: "2.0.0"
ID: sample
version: 0.0.1

modules:
  - name: sample
    type: html5
    path: public
    provides:
      - name: sample   # 1. Change the name of the provided property set so that it is different from the module name.
        public: true
    build-parameters:
      builder: npm
      ignore: [".che/", ".npmrc"]
      timeout: 15m
      requires:
        - name: sample-client
          artifacts: ["dist/*"]
          target-path: "client"
  - name: sample-client
    type: html5
    path: client
    build-parameters:
      builder: npm  # 2. Change the builder type to 'custom'.
      # 3. Add the following 2 lines:
      # commands:
      #   - npm install
      timeout: 15m
      supported-platforms: []
      npm-opts:  # 4. Remove this line and the one below it.
        execute: "install"

The final mta.yaml file should look like in the example below:


_schema-version: "2.0.0"
ID: sample
version: 0.0.1

modules:
  - name: sample
    type: html5
    path: public
    provides:
      - name: sample-provides   
        public: true
    build-parameters:
      builder: npm
      ignore: [".che/", ".npmrc"]
      timeout: 15m
      requires:
        - name: sample-client
          artifacts: ["dist/*"]
          target-path: "client"
  - name: sample-client
    type: html5
    path: client
    build-parameters:
      builder: custom  
      commands:
         - npm install
      timeout: 15m
      supported-platforms: []