filenames, when to use subobjects? about abap-file-formats HOT 4 OPEN

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

from abap-file-formats.

scoping & conventions over exceptions

from abap-file-formats.

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

from abap-file-formats.

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.

from abap-file-formats.