filenames, when to use subobjects?

[larshp]

https://github.com/SAP/abap-file-formats/blob/main/doc/specification.md#file-names

ABAP should go into ABAP files, one file, like its presented to the developer in Eclipse

Metadata for a object(R3TR) should go into a single metadata file per object, having eg. one metadata file per dynpro, per CUA etc. makes it more complex IMHO, more schemas, more things to check on serialization/deserialization time

Translations: something, I've not thought much about these yet, deferred to #106

[schneidermic0]

Thanks, for the proposal. I am struggling whether we really should go this way for the following reasons:

1. This one file might become huge, doesn't it? This is most probably a matter of taste.
2. gCTS also supports the transport of LIMU objects. This means, we will end up having multiple open transport objects containing LIMU objects for the same R3TR object. If one transport request is released only the changed parts in the particular transport request may be serialized to this one file. Changes related to the open transport request must remain unchanged in the repository. Technically, there are possibilities to implement this. We gained some experience in the area of classes. But, if we can, I would like to avoid this additional complexity whenever we can

[larshp]

scoping & conventions over exceptions

[larshp]

Lets take an example PROG ZFOOBAR, serializing each LIMU could give the following files(?)

• zfoobar.prog.zfoobar.rept.json
• zfoobar.prog.zfoobar.cuad.json
• zfoobar.prog.rezfoobar.docu.json
• zfoobar.prog.2000.dynp.json
• zfoobar.prog.json
• zfoobar.prog.abap (this is the REPS)

Serializing all JSON into single file would give

• zfoobar.prog.json
• zfoobar.prog.abap

[xtough]

Putting all the ABAP code into one *.abap file is trivial for reports but already cumbersome for classes for the reasons @schneidermic0 mentioned (like mapping LIMU METH changes to the one implementations include...) What I did not get was if @larshp is advocating one or many json files per PROG above. I understood the initial comment more in the latter sense (json files per rept, cuad, docu, dynp, etc.), which I would also be in favor of.