I agree with you 100% about not version controlling the generated code. You can version control the Maven POM that creates and packages the generated code in SVN without version controlling the generated code itself. I'm not a big advocate of providing generated bindings to one's end-users, but I just wanted to point out that it is possible without encountering the issues mentioned in the referenced article. I feel like the article brings up a non-issue when considering modern standards based Java Web services and wanted to stop the spread of potentially misleading info.
The right approach is whatever works for your team in your situation, but either approach is possible when talking JAX-WS/B only code. -----Original Message----- From: Christian Schneider [mailto:[email protected]] Sent: Friday, July 09, 2010 2:48 AM To: [email protected] Subject: Re: Maven CXF & wsdl2java code generation I think when adhering to the JAX-WS and JAXB standards your risk of incompatibilities is relatively small. So you could do this. On the other hand code generation is easy when you do it with maven and the cxf codegen tools. So my attempt is to store the wsdls in the maven repository and load them as a dependency through maven. This leaves the choice of jaxb customizations to the developer of the client and server. They even could use other aproaches. Genrally I like the idea of always generating the service code on the fly and not store the generated source in subversion. Greetings Christian Am 08.07.2010 14:48, schrieb David Valeri: > 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
