Maven project for Spring WS, JAXB/XSD to create server WAR/EAR and client JAR, also autogenerate classes from XSD

Question

It may be difficult to explain exactly what I want, so please let me do step-by-step.

Our company has long-lived Java project that uses Spring WS, XSD files to generate WSDL and those beans from WSDL. Project is compiled/built using ANT with various targets (one target to generate classes from XSD, another to generate client JAR, another to generate Server WAR/EAR). This project used to run SOAP server and also used to generate client side JAR. But there is no single source of code anymore and number of pre-generated client JARs are flying around. I need to clean this mess using Maven.

I created modular Maven project, but basically the only real child project is one that contains all the custom code, all XSDs, etc (another child project simply packages EAR from the WAR generated by first project). Since this project uses Spring WS the final WSDL file is generated dynamically when run on server.

What I have managed so far is to do following:

• generate classes from XSD manually, add those classes to the /src/main/java so that they are stored permanently, have Maven to generate the rest of Service side architecture (WAR/EAR).
• separately using the WSDL file imported from running server generate Client JAR file by using eclipse WTP plugin (create new project, drop the WSDL into it, use WTP plugin to generate files, then export project into final JAR file) and then distribute this JAR to interested parties.

This works, but as you see the process of code maintenance has problem (pregenerated classes are included into the main source), the process of generating client is at best detached from the main project. So it is a mess I would like to be able to clean up.

What I would like to be able to do is something like this:

• create Maven project that hosts XSD files
• use it to generate classes and Client JAR
• refer to this project from Server side project so that the generated classes can be referenced by server side code
• the server side project is the one that would use Spring WS and that would be able to generate EAR file

The issue I am facing is simple: the XSD files to generate WSDL dynamically should really reside in that server project, not in client project. These files need to be in /src/main/resources so they are moved to class path of built WAR/EAR file. I could use two different copies of XSD - one on client side project another on server side project, but it sounds wrong.

So my main question really is - how do I approach this project architecture using Maven so that I only use single instance of any source file (XSD, Java, etc) and I am able to conveniently generate classes from XSD, build Client JAR and server WAR/EAR. I am OK with two or more separate build commands - one generates JAR, another generate EAR from proper project sources.

Oh by the way - refactoring the XSD files is out of question - they are given to us and must be used AS IS.

Thanks, Nikolay

Answer 1

Use a separate project for the just XSDs and build another JAR with just the classes generated from the XSDs. You end up having 3 projects:

• XSD schema project
• client JAR
• server project

where the client JAR and server projects have a dependency on the XSD schema project.

You can build the whole thing in one go by using a parent project with all these projects as child modules.

If you are concerned that your client JAR is now actually two JARs (plus possibly more dependencies) you can use the shade plugin to bundle the contents of the XSD schema project's JAR in your client JAR.

Creating more projects/modules is almost always better than duplicating code.

---

Edit: To generate classes from WSDLs and XML Schema, you can use the Maven JAX-WS plugin (wsimport goal) and/or the Maven JAXB plugin.

Answer 2

We generate quite a bit of code from XSDs. Because we didn't want duplicate code, we use XML catalogs and a custom schema resolver which can resolve schemas from the classpath; I'm fairly sure apache has a schema resolver that will do this too - I remember finding it after we wrote ours. In this way one module can reference the schema from another module's artifact by declaring it as a dependency.