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+repository+as+a+service+repository
http://www.liquid-reality.de:8080/display/liquid/2008/08/20/Defining+Contract+first+webservices+by+generating+wsdl+from+java
http://www.soa-at-work.com/2010/03/why-you-should-not-deliver-client-for.html
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
