You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would it be possible to have an option to prefix packages of sources generated for a specific WSDL rather than only having the NS? For ex. service1.wsdl is in NS 'ws1' and has a schema in NS 'x'. service2.wsdl is in NS 'ws2' and has a schema in NS 'y'. The option would then allow to specify a prefix on WSDL level. If we would choose 'service1' as prefix for the first WSDL and 'service2' as prefix for the second WSDL, the code generated would respectively be in package: 'service1.x....' (for the data bindings) and 'service1.ws1....' (for the service bindings). Likewise, the code for service2 would be in package 'service2.y' and 'service2.ws2'.
Reason: we have different WSDLs from different service providers for which we generate client stubs. Packages for the generated code is automatically deduced from the service/schema namespaces. While the goal of namespaces is to be unique, this is unfortunately not always the case. We even have clashes from several WSDLs that are coming from the same provider. More specifically common datatypes that are re-used by them over different service WSDLs but not the same version. This results in the code generation to be order dependent as they are written to the same package but, so they are basically overwritten and the last one wins.
One way of thinking could be to ask the provider to fix this. However, in reality this is not always an option. fixing the WSDL ourselves is not something we want as we are not the service/schema owners and then it becomes a maintenance burden on our side. We already looked at binding customization, but AFAIK there is no way in specifying a prefix. A namespace can be written to a completely different package, but this is not what we want. The original NS should be retained but simply prefixed. We could of course all namespaces used and then prefix each of them. But this would be a very time consuming process which needs to be repeated if the WSDL changes (possibly introducing new namespaces).
So to conclude: a prefix on wsdl level (which is used as prefix for all package names generated coming from that WSDL and its schema's) would be a very easy way to make to generated code sand-boxed to a given WSDL file
Btw; the plugin is probably dependent on the options of wsimport (and I don't see any possibility there either to specify a prefix) but maybe other options exist like a post task of the plugin which prefixes the packages of the generated code...
The text was updated successfully, but these errors were encountered:
Using the configuration parameter "packageName" lets you specify a destination package for the generated code. In that case you'll lose the "hierarchy" defined in your WSDL, i.e. everything will be generated into that package even if your WSDL says otherwise.
With binding files you can remap the different packages to the ones you'd like to use. Depending on the size of your WSDL and the structure that needs to be generated this can be quite a tedious piece of work...
Would it be possible to have an option to prefix packages of sources generated for a specific WSDL rather than only having the NS? For ex. service1.wsdl is in NS 'ws1' and has a schema in NS 'x'. service2.wsdl is in NS 'ws2' and has a schema in NS 'y'. The option would then allow to specify a prefix on WSDL level. If we would choose 'service1' as prefix for the first WSDL and 'service2' as prefix for the second WSDL, the code generated would respectively be in package: 'service1.x....' (for the data bindings) and 'service1.ws1....' (for the service bindings). Likewise, the code for service2 would be in package 'service2.y' and 'service2.ws2'.
Reason: we have different WSDLs from different service providers for which we generate client stubs. Packages for the generated code is automatically deduced from the service/schema namespaces. While the goal of namespaces is to be unique, this is unfortunately not always the case. We even have clashes from several WSDLs that are coming from the same provider. More specifically common datatypes that are re-used by them over different service WSDLs but not the same version. This results in the code generation to be order dependent as they are written to the same package but, so they are basically overwritten and the last one wins.
One way of thinking could be to ask the provider to fix this. However, in reality this is not always an option. fixing the WSDL ourselves is not something we want as we are not the service/schema owners and then it becomes a maintenance burden on our side. We already looked at binding customization, but AFAIK there is no way in specifying a prefix. A namespace can be written to a completely different package, but this is not what we want. The original NS should be retained but simply prefixed. We could of course all namespaces used and then prefix each of them. But this would be a very time consuming process which needs to be repeated if the WSDL changes (possibly introducing new namespaces).
So to conclude: a prefix on wsdl level (which is used as prefix for all package names generated coming from that WSDL and its schema's) would be a very easy way to make to generated code sand-boxed to a given WSDL file
Btw; the plugin is probably dependent on the options of wsimport (and I don't see any possibility there either to specify a prefix) but maybe other options exist like a post task of the plugin which prefixes the packages of the generated code...
The text was updated successfully, but these errors were encountered: