Add switch for defining mta.yaml filename

[rauar]

We have multiple mta.yaml files with small variations in their filename and mta content.

E.g. mta-cf.yaml and mta-xsa.yaml (in this case we use the same code base for different packagings depending on the target platform).

Right now I see only the option to specify the root directory of the sources (which must contain exactly mta.yaml). It would make more sense to specify the file (optionally including an absolute/relative path) containing the typical mta.yaml content.

Example:

Building the cf version of our product would be done like this:

mbt -f mta-cf.yaml

and the XSA version:

mbt -f mta-xsa.yaml

while both projects are built in the exactly same directory.

PS: e.g. Apache Maven allows exactly this (mvn -f pom_custom.xml).

[katunin-ng]

Hi,

Please consider implementing the differences in the MTA extension files. So you will have the common part defined in the single mta.yaml and specific configurations for CF and XSA in the corresponding extensions. Then you can pass the extension to the build using -e option (see the details in the Usage chapter: https://sap.github.io/cloud-mta-build-tool/usage/#one-step-build.
More general information about MTA extensions you can find here: https://www.sap.com/documents/2016/06/e2f618e4-757c-0010-82c7-eda71af511fa.html.

Regards
Natalia

[rauar]

MTA extensions aim almost exclusively at adding/customizing deployment properties for existing modules defined in the MTA itself. That's a very limited feature scope. As a consequence MTA extensions are not appropriate for structural differences in the MTA - they do not allow adding additional modules (module.type and module.path properties are not allowed are not allowed inside an extension descriptor) nor do they allow switching the path to variant-specific subfolders.

In my initial example l need additional modules for the XSA variant which should not be included in the CF variant. That cannot be done with MTA extensions and I think that's not the purpose of MTA extensions at all.

In contrast to that my initial proposal of allowing specifying the MTA descriptor file as argument for mbt is much more flexible, easy to implement, does not conflict with existing functionality or design aspects of the mbt tool and even follows good-practices seen in other wide-spread tools.

GNU Make:

Usage: make [options] [target] ...
Options:
...
  -f FILE, --file=FILE, --makefile=FILE
...

Apache Maven:

usage: mvn [options] [<goal(s)>] [<phase(s)>]
Options:
...
 -f,--file <arg>                        Force the use of an alternate POM file (or directory with pom.xml).
...

Node.js:
Usage: node [options] **[ script.js ]** [arguments]

Ruby Rake:

rake [-f rakefile] {options} targets...

Options are ...
...
    -f, --rakefile [FILENAME]        Use FILENAME as the rakefile to search for.

[katunin-ng]

Hi Alex,

Wrt "MTA extensions aim almost exclusively at adding/customizing deployment properties for existing modules defined in the MTA itself. " It is not quite correct. You can influence the build and packaging process using the mta extensions passed during the MTA build step. In your care, when you have modules relevant for XSA target only, I would recommend you to define them in the mta.yaml descriptor with build parameter: supported-platforms: [XSA] to package them for XSA only and in the relevant mta extension use the build-parameters "no-source: true" to avoid their build during build for CF. You can read more about these features here: https://sap.github.io/cloud-mta-build-tool/configuration/.

If you have other differences, please elaborate and I can assist with configuring them using the single mta.yaml approach.

The feature that you describe could be useful, but currently, there is no mich demand for that. . Therefore, we are not planning to introduce this enhancement soon. However, I will mark this issue as we are interested in the contribution for. And probably it will be provided by the community.

Regards
Natalia

[rauar]

Hi Natalia,

I appreciate your offer for support but what you propose is going to be a very complicated solution for a very simple problem. It would result in one single, bloated mta.yaml covering all potential build variants. Plus in case we would have future variants (e.g. a lite version and a full-features version) which are not related to CF vs. XSA we would be again stuck.

I had a look into the sources and while the "Location" object already carries a mtaFilename property (which is good) the code around the Location object is doing implicit assumptions (depending on if we are dealing with a development or a deployment descriptor) and it seems to be used for multiple goals.

I will stick with a single copy command in my shell wrapper which copies the mta.yaml from a given input file. Not nice as well but at least simple.

BR, Alex

[mdejavue]

Please implement this switch. I actually can't believe it is not existant. Whenever you want to deploy a copy of your MTA in the same target landscape you have to change the "ID" field. Even the MTA extension does not let you change the "ID" field. (at least it has no impact during deployment)

[rauar]

Can't believe it too. This is basic/standard functionality for CLI commands. Like selling cars without wheels 🙈

[ThomasSwolfs]

@katunin-ng as mentioned above, this flag would be really useful. I also cannot understand why this is not a possibility yet.. Any update on this topic?

[mocotrah]

@katunin-ng I am also interested in this topic, any news?
In my case, I have a repo with many applications and using lerna to be able to use common libraries in these apps. I need to build 2 different mtars which will serve for 2 purposes. One is for classical apps for clients, one is for admin apps used by the providers of our project. The first mta (for client apps) is already huge + mtaexts for diffferent environments and I don't want to mix inside it admin apps.

[mocotrah]

PR in progress: #1154