Storage of Elements obtained by Retrieve in a path compatible with the Endevor Bridge for Git about che-che4z-explorer-for-endevor

[FALLAI-Denis]

@Alexandru-Dumitru

Systematically prompting for the storage location of a retrieved Element would be the simplest and most universal solution, but with two drawbacks:

• heavy use for a large number of elements
• lack of control in relation to the standards of use desired by the site.

I don't think it is necessary to have a different solution for the main Elements, and the dependent Elements. The same mechanism must apply to both, (especially since the same Element can sometimes be main and sometimes be dependent).

I propose to implement a mechanism to parse the map location in Endevor, in the form of an implicit regular expression, representing a selection filter, and to exploit this information to determine the path for local storage location.
Several selection filters could be declared, parsed in the order of their declarations, and as soon as a filter is satisfied with respect to the map location in Endevor then it determines the path for local storage location, which could be of 3 types:

• absolute path on the workstation : string, begin with /
• relative path in the workspace : string, does'nt begin with /
• request to enter the local location : keyword prompt

The regular expression to filter the map locations in Endevor would use the syntax of the Explorer for Endevor filters, (to see whether it is also necessary to take into account the Zowe profile used, and the name of the Endevor Web Services configuration).
Either: /environment/stagenum/system/subsystem/type/element

The implementation of this mechanism could be configured as follows:

{
  wheretostore: [
    {map: "/*/*/*/APPA/*/*",
     path:"{system}/{subsystem}/{type}/{element}"},
    {map:"/*/*/*/*/COPYCOB/*",
     path:"/d/e4e/.imports/{element}"},
    {map:"/*/*/*/*/*/*";
     path: prompt}
  ]
}

In this example:

• the first map filter selects all the Elements of the "APPA" subsystem (current Application of the Git Repository) and stores them in Workspace folders which take the naming of the System, Subsystem, Type
• the second map filter, if first do'nt satisfy, selects all the Elements of Type "COPYCOB" and stores them in the D:\e4e\.imports folder on a Windows workstation
• the third map filter, if first and second do'nt satisfy, selects all the Elements and asks where to store them. The third filter could be implied.

Filtering for a level in the Endevor path can be on the entire level code, *, or part of the code, AA*.
The name of the Element is part of the filter and the target of local storage, which can be used to filter on codifications of Elements, and possibly to locally rename an Element.

[Alexandru-Dumitru]

Hi @FALLAI-Denis,

Thanks for bringing this up.
We'll discuss it and adjust the download path accordingly.

[FALLAI-Denis]

@Alexandru-Dumitru

After reflection and various experiments, I think that one should not impose one path more than another for the storage of an Element during a "retrieve".

You must leave the choice to the user of the location where the recovered element will be saved (the retieved Elements if using dependencies, which moreover may not be stored in the same place as the main Element).

Use case:

• use of a Git repository for Application "A"
• clone Git repository on workstation, and open root folder in VS Code
• sources are organized in folders in the Git repository / Workspace according to their nature
• Application "A" must access Application "B", for this we retrieve the interface areas (COPYBOOKs) of Application "B" from Endevor, by a "retrieve"
• but we do not want the Elements of Application "B" to be stored in the folders of the Git repository of Application "A"
• we store them in a Workspace folder (or outside the Workspace) reserved for this purpose, and which is "ignored" in the Git tracking process (.gitignore)
• we therefore want the interface of the "retrieve" command to request the storage path for the retrieved Elements.

[Alexandru-Dumitru]

Hi @FALLAI-Denis ,

Thanks for the input. Do you think an input box is necessary or it's sufficient to have these values in settings? Something like:

{
  endevor: {
     retrievePath: "/x/y/z",
     dependenciesRetrievePath: "/x/y/z",
     promptForRetrievePath: false (true)
  }
}

We can go even a step further if needed, and have an option that enables prompting all the time, but I am thinking of the case where users might just want to retrieve to the current workspace, no questions asked. We might have a precedence in place, something like inputBox (if present) -> settings (if present) -> default to workspace