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:ch...@die-schneider.net]
Sent: Wednesday, July 07, 2010 2:23 AM
To: users@cxf.apache.org
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
