Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

INTF bits missing #86

Closed
larshp opened this issue May 10, 2021 · 15 comments
Closed

INTF bits missing #86

larshp opened this issue May 10, 2021 · 15 comments
Labels
bug Something isn't working

Comments

@larshp
Copy link
Collaborator

larshp commented May 10, 2021

I think the following are missing in the INTF file definition?

  • Dokumentation long texts
  • Text elements
  • Proxy flags?
@schneidermic0
Copy link
Contributor

Yes, you are right, documentation is missing. This needs to be added.

There shouldn't be text elements for interfaces

Which proxy flags do you mean?

@larshp
Copy link
Collaborator Author

larshp commented May 11, 2021

Proxy: as far as I remember the proxy generation sets a special flag on the interface so it's recognized as a proxy object, not sure if it can be derived from the source code, SEOCLASSDF-CLSPROXY

Also not sure if these can be left out/derrived,

  • SEOCLASSDF-CATEGORY
  • TADIR-GENERATED

@schneidermic0 schneidermic0 added the bug Something isn't working label May 12, 2021
@schneidermic0
Copy link
Contributor

We checked it. You are right, the fields CATEGORY and CLSPROXY should be added. I suggest to show CLSPROXY only if a value it is true.

TADIR-GENERATED has to be double-checked. I am also not 100% sure whether this is needed.

@larshp
Copy link
Collaborator Author

larshp commented May 12, 2021

only true: its a json design decision see #61 (comment)

@schneidermic0
Copy link
Contributor

TADIR-GENERATED has to be double-checked. I am also not 100% sure whether this is needed.

Just as information: I had just a short discussion with colleagues responsible for the change and transport system. They plan to have a dedicated file for some metadata representing TADIR information. I have asked them to contribute their proposal to this repository as soon as they have a first version.

@larshp
Copy link
Collaborator Author

larshp commented May 12, 2021

basically GENFLAG is the only one needed? https://www.se80.co.uk/saptables/t/tadi/tadir.htm, master language is in the existing metadata file

so will it be one file with one field? one file with all objects of a repository, or one extra file per object?

@schneidermic0
Copy link
Contributor

I also haven't seen the proposal, yet. I understood it will contain more than one field and it will be one file per object.

@larshp
Copy link
Collaborator Author

larshp commented May 12, 2021

from my point of view, the json file is meant to contain the metadata for the object, so I dont see any reason for adding more files for the same object

@ulrichauer
Copy link

We distinguish object metadata and transport process metadata and try to separate that.
The long term goal is to get rid of the transport process metadata, but as you may have realized we need to keep things compatible as long as classic CTS is used in parallel to gCTS.
The table TADIR contains object metadata (e.g. master language, package assignment) which may be moved elsewhere. But it also contains transport process metadata. There are other tables containing transport process metadata which we also need to carry along with the objects (e.g. modification metadata which will only disappear in the long term).

@ulrichauer
Copy link

basically GENFLAG is the only one needed? https://www.se80.co.uk/saptables/t/tadi/tadir.htm, master language is in the existing metadata file

so will it be one file with one field? one file with all objects of a repository, or one extra file per object?

One metadata file per object.

@larshp
Copy link
Collaborator Author

larshp commented May 19, 2021

@ulrichauer thanks 👍

we need to define what's in scope for the abap-file-formats, object metadata and/or transport process metadata

I guess transport process metadata should not be edited by a developer? And as a developer I'd personally like not to see it. However its needed for deployment/transport (right?), so I'd leave it to the deployment mechanism to define transport process metadata.

@larshp
Copy link
Collaborator Author

larshp commented May 25, 2021

@schneidermic0 any thoughts? we need to decide this to move forward

@larshp
Copy link
Collaborator Author

larshp commented Jul 19, 2021

Status:

@schneidermic0
Copy link
Contributor

I suggest to open two new issues:

  1. How to handle documentation (especially SAPScript).
  2. Transport process metadata

Then we can close this issue.

@schneidermic0
Copy link
Contributor

I have created following issues:

  1. File Formats for Documentation #130
  2. Metadata Needed for Transport/Deployment #131

I think we can close this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants