If you distribute the JAX-WS annotated interfaces and JAX-B annotated data binding classes that were created by wsdl2java, that library has absolutely zero runtime dependency on CXF. The CXF dependency only exists at build time for the artifact containing the generated code. CXF is used only as a build dependency through plug-in configuration and will not be involved in the transitive dependency resolution in Maven when the artifact is included as a dependency by your end-users. For the most part, your service implementation code is ignorant of CXF as well. Your service code can either use the JAX-WS APIs to publish a service endpoint or it can be wired up by CXF in a Spring configuration file. Either way, your implementation code will usually be completely ignorant of which JAX-WS implementation is in use as all of the JAX-WS implementation specific stuff can be done in Spring with CXF or using other external configuration files when using other JAX-WS implementations.
So, you can distribute the generated code in one JAR and sample implementation classes in another JAR and neither needs to be CXF specific if you code to the JAX-WS API. It is only in your WAR that you bring in a JAX-WS implementation and provide CXF specific configuration in a Spring file or in CXF aware Java code. One advantage of having a central person generate the code is when you have a schema that needs lots of attention to generate code from. For example, name collisions, and data type issues that require a XJB file or tweaks in the schema to make work. Rather than having all of your service's users in your company waste time figuring out the needed customizations, you have one person do it and get it working right. Regardless of if you distribute generated code or not, it is still a good idea to host your WSDLs in a well managed location for reference by everyone involved and your end-users will still need to learn enough about JAX-WS to know how to use your generated code in their application. Christian's referenced article argues against providing a client that is based on a specific stack and this was a common issue in the days before JAX-WS; if you program to the API and provide only JAX-WS/JAX-B annotated code, it is a non-issue. -----Original Message----- From: Christian Schneider [mailto:[email protected]] Sent: Wednesday, July 07, 2010 2:23 AM To: [email protected] Subject: Re: Maven CXF & wsdl2java code generation Hi Jay, you can create a maven project that only does the code generation. Then this project could be shared. In the war project you could then reference the project with the generated code as a maven dependency. While this is well possible to do I strongly advise you to not do it. For some time we created client jars for the users of services. That meant that they could start very easy as they simply had to reference the client jar and retrieve the service with a factory. The problem is that in the end you create much more problems doing this in the long run. The client jars had to reference the whole cxf stack to work. That meant the developer who included it made his project dependent on these libs. This could create some problems with his own current stack. The real problems start when you try to include several client jars. Over time you will need to build the client jars using newer version of cxf or spring. Then when someone includes the newer and older clients maven will have to choose which version to use. This can create incompatibilities. So my advise is to deploy the wsdl to a central repository and show the client and server developers how to do code generation and the spring config with a good sample project (like the wsdl_first example). It is also a good idea to have a central person that helps the teams set up the initial service configuration. Some articles that could be interesting for you are the following: http://www.liquid-reality.de:8080/display/liquid/2009/09/03/Use+maven+reposi tory+as+a+service+repository http://www.liquid-reality.de:8080/display/liquid/2008/08/20/Defining+Contrac t+first+webservices+by+generating+wsdl+from+java http://www.soa-at-work.com/2010/03/why-you-should-not-deliver-client-for.htm l Greetings Christian Am 07.07.2010 01:41, schrieb jaybytez: > Thanks for the reference to wsdl_first example, it was very helpful. > > One last question, what would it take to do the following with the wsdl2java > and is it even possible. > > Run wsdl2java and produce the following: > 1) jar file the interface service class > 2) jar file the sample implementation classes > 3) war the actual web service endpoint web project > > The goal is that the interfaces could be compiled and package separately so > that both the web service endpoint (war) could use the jar and the > implementation jar could use the interface jar. > > And this would allow a technical lead to build these projects and just hand > off the implementation classes (jar development) to a separate team. > > Thanks for your help, > > Jay -- ---- http://www.liquid-reality.de
