I'm implementing a dozen of JAX-WS endpoints and clients that share the same XSD schema, but with slightly different WSDLs. The schema is an "industry standard", and I've been promised that it is never going to change. As of now, JAXB classes and JAX-WS artifacts are regenerated each time during build (I use a NetBeans-generated POM file). With this approach, I've faced a number of well-known problems with no known solutions:
- wsimport is not capable of processing several WSDLs at once; therefore, with each wsimport pass, an ObjectFactory is overwritten, in my case making impossible to do a generic JAXBElement<> unmarshal;
- no way to move JAXB classes into separate, shared project (i.e., to supply wsimport with pre-compiled JAXB JAR);
- I want JAXB classes to have custom toString() methods that use different expressions to form a string. (JAXB2 Basics ToString plugin supports only primitive toString algorithm);
- I also want JAXB classes to have an accept(Visitor) method;
- generated JAXB classes are not JPA friendly out-of-the-box (the problem more or less addressed by HyperJAXB).
That's why right now I'm feeling strong temptation to copy generated classes to my src/main, to apply code modifications once and forever, and to purge wsimport/xjc tasks from my POM. This will solve all the described problems at once, and significantly reduce build times as well. The only disadvantage is, if the schema does change (very unlikely!), then I'm fawked :)
Did I miss any other risks and caveats? Assuming the schema is not going to change, is it safe to drop regeneration in favour of once-generated artifacts?