Optionally, you can define the builder behavior by configuring the parameters in the
build-parameters section in the
mta.yaml file for each module or globally.
For each module, the Cloud MTA Build Tool performs a build operation using a default technology specific for the module type, for example, the
For the complete list of available builders and their default behaviors, see Builders Execution Commands.
To find out which builder is applied to a module if the
builder parameters are not explicitly set in the MTA development descriptor file (
mta.yaml), see Modules' default builder configuration.
The following sections describe in detail how to configure each of the supported builders.
Configuring a builder for a module
To use a non-default builder for a module, specify its name in the builder parameter.
- name: module1 type: java build-parameters: builder: zip
Configuring build order
You can define the dependencies between modules to ensure that they are built in a certain order. In addition, you can use the build results of one module to build another module. Also you can can configure build steps that are performed before building any of the modules.
Defining module build order
To define the build order of modules, in the
mta.yaml file, add a
requires section under the
build-parameters section of the dependent module; that is, a module that should be built only after building another required module. Then specify the required module name as a property of the dependent module’s
mta.yaml file below demonstrates how to build module A after module B:
ID: myproject _schema-version: '3.1' version: 0.0.1 modules: - name: A type: html5 path: pathtomoduleA build-parameters: requires: - name: B - name: B type: html5 path: pathtomoduleB
NOTE: The order of modules in the
mta.yamlfile is not important as long as the
requiressections have been coded with the relevant dependencies.
CAUTION: Cyclical dependencies are not allowed. If such dependencies are found, the build fails.
Using build results for building another module
If you want to use the build results of module B for building module A, modify the
requires section as follows:
ID: myproject _schema-version: '3.1' version: 0.0.1 modules: - name: A type: html5 path: pathtomoduleA build-parameters: requires: - name: B artifacts: ["*"] target-path: "newfolder" - name: B type: html5 path: pathtomoduleB
Configuring a global build
If you want to run addtional build steps before running builders of the specific modules, define it by using the
build-parameters section at global level in the
mta.yaml file as follows:
ID: myproject _schema-version: '3.1' version: 0.0.1 build-parameters: before-all: - builder: npm modules: ...
You can configure any of the supported builders. Also, you can list several builders and they will run in the specified order.
ID: myproject _schema-version: '3.1' version: 0.0.1 build-parameters: before-all: builders: - builder: custom commands: - npm run script1 - builder: grunt modules: ...
NOTE: Only the following build parameters are considered when configuring a builder at the global level:
fetcher builder can be used for packaging already available Maven artifacts into a multitarget application archive as the module’s build results.
- name: my_module build-parameters: builder: fetcher fetcher-opts: repo-type: maven repo-coordinates: mygroup:myart:1.0.0
repo-coordinates parameter is a string of the form
This is equivalent to a Maven dependency command, delegating the specified coordinates to the standard Maven dependency mechanism:
mvn dependency:copy -Dartifact=mygroup:myart:1.0.0
You can define your own build commands by configuring a
custom builder as follows:
- name: my_module build-parameters: builder: custom commands: - npm install - grunt - npm prune --production
When used for configuring a module builder, you can leave the
commands parameter list empty:
- name: my_module build-parameters: builder: custom commands: 
In this case, no build is performed and the module's root folder or a folder specified in the
build-result is packaged into the MTA archive.
Configuring module build artifacts to package into MTA archive
You can configure the following build parameters to define artifacts to package into the MTA archive for the specific module:
For other builders:
|A path to the build results that should be packaged.|
||None||Files and/or subfolders to exclude from the package.
The provided paths should be relative to the build result folder, which can be the module's root folder (default) or the folder specified in the
- name: module1 type: java build-parameters: builder: zip build-result: myfolder ignore: ["*.txt", "mtaignore/"] # In this example, the following will not be packaged in to MTA archive: # all files with the"txt" extension and the "mtaignore" folder within the "myfolder" directory.
NOTE: These parameters are not considered for the
Configuring and packaging modules according to target platforms
If you want to control which modules should be packaged into a multitarget application archive for a specific platform, use the
supported-platforms build parameter as follows:
ID: myproject _schema-version: '2.0' version: 0.0.1 modules: - name: A type: html5 path: pathtomoduleA build-parameters: supported-platforms: [NEO, CF] - name: B type: html5 path: pathtomoduleB build-parameters: supported-platforms: [NEO] - name: C type: html5 path: pathtomoduleC build-parameters: supported-platforms: 
If you build an application with the multitarget application descriptor above for a
CF (Cloud Foundry) target, all its modules are built, but the resulting multitarget application archive and deployment descriptor include module A only.
If you build the same application for a
NEO target, the multitarget application archive includes module A and module B.
If you have a module C with an empty supported platform list, it is never included in any multitarget application archive, regardless of the target platform of the specific multitarget application build.
supported-platforms build parameter is not used, the module is packaged for any target platform.
You can use these values or any combination of these values for the
supported-platforms build parameter:
CFfor the SAP Cloud Platform Cloud Foundry environment
NEOfor the SAP Cloud Platform Neo environment
XSAfor the SAP HANA XS advanced model
Configuring timeout sessions
When you build a specific module, there is a default 5-minute timeout allowance. After this time, the build will fail. You can configure the time allowed for timeout when performing a build by adding the
timeoutproperty to the module build parameters. The timeout property uses the
<number of hours>h<number of minutes>m<number of seconds>sformat.
- name: module1 type: java build-parameters: timeout: 6m30s
Also, you can use this parameter to define timeout for the global
Configuring the build artifact name
The module build results are by default packaged into the resulting archive under the name “data”. You can change this name as needed using the
modules: - name: db type: hdb path: db build-parameters: build-artifact-name: myfileName
NOTE: The file extension is not configurable; it is predefined by the module type (.zip or .war).
Configuring a module that does not have source code to build and package
There are use cases when a module does not have any source code that should be built and therefore there are no build results to be packaged into the MTA archive. The module definition in the MTA descriptor is the only input that is required to deploy the module into the target environment. You can instruct the tool to treat the module as such by setting the build parameter
modules: - name: module1 ... build-parameters: no-source: true
true, the tool does not validate the
pathproperty, so it can be omitted as shown in the example above. No action is performed during the module's build step, so all parameters configuring the module build behaviour, e.g.
ignore, etc. are ignored. There is no content associated with this module in the result MTA archive. The rest of the module processing is the same as when the parameter is not provided, e.g. the entry in the generated the deployment descriptor is created based on