If the wsdl is in a jar, I know the CXF wsdl2java tooling (maven plugins) can grab the wsdl out of the jar and generate code from it. Thus, a "common" jar could have the wsdl and the common generated stuff (like the jaxb types, the service interface, etc...) and the others could use it.
Dan On Thursday 09 October 2008 3:10:23 pm Hayes, Peter wrote: > How do you end up generating the server side skeleton files? Is this > done as part of the module with the WSDL? > > -----Original Message----- > From: Kalle Korhonen [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 09, 2008 3:00 PM > To: Maven Users List > Subject: Re: WSDL as Maven artifact > > I think in typical cases a single WSDL is too small of a source fragment > to > be a build artifact. The pattern I've often followed is that I keep the > wsdl > and the generated client stubs in one module with an obvious packaging > type > jar, then use the jar both on the client and the server side. > > Kalle > > > On Thu, Oct 9, 2008 at 10:02 AM, Hayes, Peter <[EMAIL PROTECTED]> > > wrote: > > We are building web services and in our approach multiple maven > > projects > > > would be consumers of the service WSDL in order to generate their > > server / > > > client stubs. I think it would be good to have a project of packaging > > type > > > wsdl and then have consumer projects depend on that artifact. Has > > anybody > > > tried to do this or is there a better pattern for doing this? > > > > I found one reference on the web about this : > > > > http://myarch.com/using-maven-repository-as-web-services-registry > > > > Possibly the hard part would be integrating with existing wsdl2java > > plugins > > > that expect a file path to the WSDL file. I would guess that I would > > have > > > to customize one to automatically grab depencies of type wsdl and then > > pass > > > them to the code generator. > > > > > > Peter Hayes [image: LinkedIn > > Profile]<http://www.linkedin.com/in/petehayes> > > > Architecture & Shared Technology Services | Fidelity Investments > > Management > > > Technology > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
