Open thijsvolders opened 3 years ago
@sajinieKavindya I hope you can find time to have a look at my question. Many thanks!
I have this problem too. To increase browsability of Reg projects we have structured the file location as it will be in the registry. This now breaks replacing the old, slow car module with the new, fast vscode-plugin.. A speedy fix would be appreciated.
Description: I am in the process to convert ESB-style maven-car-plugin projects to its vscode-plugin counterparts. Building with the vscode plugin is much faster and thus we are converting. We run into a problem after deploying the vscode-plugin produced CAR. The vscode plugin treats the artifact.xml file differently then the ESB-style plugins did and that results in a change in the registry path of resources after the project has been converted.
I have a project with a registry resource. The artifact.xml of the registry project has the following artifact (The groupId is removed for readability):
I build the CAR with the ESB-style plugins and I get the following in a registry-info.xml file in the CAR for this resource:
If I then convert the project to a vscode-plugin style. The artifact.xml of the registry is untouched, just moved into the appropriate folder and then I build the CAR. The registry info equivalent file now shows ( please see the file-element contents ):
The effect of this change is that the registry-resource, when referenced in source-code (f.e. a sequence) is actually no longer available in gov:can/ubl21/common but its now available in gov:can/ubl21/common/xsd/UBL/common/
This is a problem for us as all references to the registry-items in sourcecode became invalid instantly...
We're using subfolders in the registry-resources folder on disk to organise registry resources and keep it tidy. With the vscode plugin we must now choose to either flatten everything in the src/main/registry-resources folder (so without subfolders) or we must change all references in each service we have to use the new location. Neither is preferred and I prefer the vscode plugin to be binary-compatible with the ESB-style plugins. Would there be a reason why its not?
Can you please consider to change the vscode plugin to respect the resource-definitions as was the case with the ESB-style plugins so that we don't have to do tedious conversions !?
Suggested Labels:
Suggested Assignees:
Affected Product Version: 5.2.29
OS, DB, other environment details and versions:
Steps to reproduce:
Related Issues: