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

Incompatible CAR files when converted to vscode-plugin build #74

Open
thijsvolders opened this issue Oct 29, 2020 · 3 comments
Open

Incompatible CAR files when converted to vscode-plugin build #74

thijsvolders opened this issue Oct 29, 2020 · 3 comments
Assignees

Comments

@thijsvolders
Copy link
Contributor

thijsvolders commented Oct 29, 2020

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):

<artifact groupId=" ...  " name="UBL-XAdESv132-2.1_xsd" serverRole="EnterpriseIntegrator" type="registry/resource" version="1.15.5-SNAPSHOT">
        <item>
            <file>xsd/UBL/common/UBL-XAdESv132-2.1.xsd</file>
            <path>/_system/governance/can/ubl21/common</path>
            <mediaType>application/x-xsd+xml</mediaType>
        </item>
    </artifact>

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:

<resources>
    <item>
        <file>UBL-XAdESv132-2.1.xsd</file>
        <path>/_system/governance/can/ubl21/common</path>
        <mediaType>application/x-xsd+xml</mediaType>
    </item>
</resources>

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 ):

<resources>
    <item>
        <file>xsd/UBL/common/UBL-XAdESv132-2.1.xsd</file>
        <path>/_system/governance/can/ubl21/common</path>
        <mediaType>application/x-xsd+xml</mediaType>
    </item>
</resources>

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:

  • sajinieKavindya

Affected Product Version:
5.2.29

OS, DB, other environment details and versions:

  • irrelevant

Steps to reproduce:

Related Issues:

@thijsvolders
Copy link
Contributor Author

@sajinieKavindya I hope you can find time to have a look at my question. Many thanks!

@sumsum77
Copy link

sumsum77 commented Feb 2, 2021

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.

@gspadotto
Copy link

Has this issue been fixed or - 4 years after - it's still there?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants