Open oliviercailloux opened 2 years ago
The authfile is able to handle cases where a wsdl behind unameA/pwdA imports wsdl/xsd from different URL behind unameB/pwdB. In general, a WSDL can import arbitrary number of documents from different URLs and accessible to different users each having different password.
True. But a simplification for the (I believe, common) case where the user needs only one pair of username and password would be most welcome.
Alternatively, for full flexibility, the plugin could look at triplets of variables WSDL_URL_KEYWORD, WSDL_USERNAME_KEYWORD, WSDL_PASSWORD_KEYWORD for any user-defined keyword.
Example: WSDL_URL_MAIN = "http://server1.example.com/" WSDL_USERNAME_MAIN = "my-username-on-server-1" WSDL_PASSWORD_MAIN = "my-password-on-server-1" WSDL_URL_SECOND = "http://server2.example.com/" WSDL_USERNAME_SECOND = "my-username-on-server-2" WSDL_PASSWORD_SECOND = "my-password-on-server-2"
Thinking about it, just adding an option -Xauth
whose contents would be the authorization information (whose usage would be exclusive from the current option -Xauthfile
whose contents indicate a file containing the authorization information) would solve the problem, I think.
Context
Use the
com.sun.xml.ws:jaxws-maven-plugin
task to “wsimport” a WSDL file from some URL that requires authentication.Current behavior
One needs to use something like this.
The file
WSDL_credentials.txt
must contain something like (for example):https://encoded-username:encoded-password@*
.Desired behavior
It would be great to be able to use some more common mechanism for authentication, like environment variables. Something like this would be great: provide some way to tell the plugin to first look at system properties; if this fails, look at environment variables; if this fails, look at some configuration file. (Also, the syntax of that file could be simplified, I think, though this is of lower priority.)
Rationale
When, for example, building an application on a continuous integration server, the need of generating a file with this unusual syntax and with encoded data makes it cumbersome to build. It is also very unusual, and thus does not integrate with various mechanisms that providers of CI platforms make available to ease life of developers facing the need to use secrets to authenticate to various sources (example). I had to develop and test a custom GitHub action, for example, just to build some software using this JAX-WS task.
Thanks for this useful plugin, in any case!