We Keep Coding

How to properly use the server stubs generated from a swagger specification?

I'm using Swagger 2.0 and swagger-codegen (actually the swagger-codegen-plugin for Maven) to specify,document and generate an API, with Java as the target language.
The project is already setup to build the server stubs (JAX-RS) and documentation, and Eclipse recognizes the generated code in the project buildPath.
I'm not sure of what is the proper workflow from here. :-/
I don't think I should modify the generated classes, otherwise my changes would be overwritten whenever I change the swagger spec, an I expect it will change as I think more about the API as the development goes on.
What should I do then? Inherit from the generated classes (which ones?) or include them in my own classes?

There are two steps to the solution here.
Add **/*Controller.java or **/*Impl.java to .swagger-codegen-ignore file. Depending on the language used the default implementation is provided in a *Controller.java or *Impl.java file. Once the default implementation is excluded from generation, you can implement the generated interfaces in your own class. The code in your own class will not get refreshed on mvn clean.
.swagger-codegen-ignore file itself is an auto-generated file hence whatever you add in step 1 gets refreshed when you do a mvn clean. To avoid this keep your version of .swagger-codegen-ignore in your resources folder and add the below plugin to your pom, to copy the file at the start of the Maven lifecycle:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<executions>
<execution>
<id>copy-resources</id>
<phase>initialize</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/generated/swagger</outputDirectory>
<resources>
<resource>
<directory>${basedir}/src/main/resources</directory>
<includes>
<include>.swagger-codegen-ignore</include>
</includes>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>

I believe you will need to update the Impl classes, e.g. PetApiServiceImpl.
If you want to skip certain files (e.g. Impl classes) during code regeneration, you can add the files to .swagger-codegen-ignore.

Using jaxws-maven-plugin with -clientjar option

I'm using jaxws-maven-plugin to execute wsimport for a web service consumer app. I'm using the -clientjar option on wsimport which was introduced with JAX-WS 2.2.2 RI in 2010. I do this because I want to bundle the WSDL within the jar.
I don't have a problem crafting the pom. For plugin configuration I do something like:
<configuration>
...
<args>
<arg>-clientjar</arg>
<arg>bundled-wsdl.jar</arg>
</args>
</configuration>
When I execute a build my created jar, lets call it myapp.jar, has file bundled-wsdl.jar within it. Inside the bundled-wsdl.jar's META-INF directory I find the wsdl and xsd just as I like them. I'm also quite happy with the generated java code that come as a result of using the -clientjar option. So far so good.
But this stuff should be in myapp.jar's META-INF, right?
The fact that it sits within bundled-wsdl.jar's META-INF doesn't help me a lot.
The funny thing is that I do in fact get a wsdl file in myapp.jar's META-INF which makes the application actually work. How it gets there I don't know. Also the xsd file isn't there, only in bundled-wsdl.jar's META-INF.
The basic question is how to correctly use wsimport -clientjar option in a Maven project ?
Java 1.7.0_45.

The -clientjar option is really poorly documented, IMHO.
Here's how I believe it works:
When the -clientjar <jarfile> option is used three things are happening:
You'll get a <jarfile> generated in the directory pointed to by
the -d argument to the wsimport tool. This will contain within
it both WSDL and any relevant XSD files as well. This little bundle will not be used for anything at all. If you want to make use of it it would be entirely up to you. But before you do see (2) below. I'm not sure what to use this jarfile for other than as a form of documentation.
You'll get a copy of the WSDL put into a file called
META-INF/wsdl/<svcname>.wsdl. The generated classes will use this
file in the no-arg proxy constructor. So this is what will actually
be used if you request a bundled WSDL file with the -clientjar
option.
The generated code will change so that wsdlLocation, if you are using the default no-arg constructor on the #WebServiceClient class, will be that of the bundled WSDL (from (2)), rather than the remote WSDL. Indeed if you use -wsdllocation on your command line together with -clientjar then whatever you specify with -wsdllocation will have no effect as -clientjar will take precedence.
So we must focus on (2) and (3) because that's the only one being actually used ... at least if you use the generated code as-is.
It is interesting to note that the result of (2) is only a WSDL file. This file may have embedded links to XSD files but as far as I can tell such link will never be followed. The reason is that when we say a web service consumer needs the WSDL at runtime it really only needs the WSDL itself, at not the schema. The schema is "hardcoded" into the consumer and there's no way of changing it at runtime. Hence there's no reason to read schema information at runtime. (THIS IS FROM MY UNDERSTANDING)
Second thing to note about the WSDL that's included with (2): It is really just a copy of the original WSDL so it may not have endpoint you want. Actually in most cases it won't. This means that in this situation you'll need to set the endpoint yourself :
// Use no-arg constructor. Means it uses the WSDL bundled into the
// META-INF/wsdl directory rather than trying to retrieve WSDL over the
// network.
service = new HelloSvc_Service();
hello = service.getHelloSvcPort();
// Since we're using a bundled WSDL the web service URL cannot
// be derived from that (it would be wrong!). So we have to set
// it explicitly.
((BindingProvider) hello).getRequestContext().put(
BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
"http://myhellowebservice-address");

The documentation for this plugin is a joke. A workaround is to manually extract the contents from the client jar after it is created like follows:
<build>
<plugins>
<plugin>
<!--
Generates JAXWS classes for all of the WSDL files in $[project.base.dir}/src/wsdl.
-->
<groupId>org.jvnet.jax-ws-commons</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<version>2.3</version>
<executions>
<execution>
<goals>
<goal>wsimport</goal>
</goals>
<configuration>
<args>
<arg>-clientjar</arg>
<arg>${project.build.directory}/wsimport-client.jar</arg>
</args>
<wsdlUrls>
<wsdlUrl>https://webservice.com/service.wsdl</wsdlUrl>
</wsdlUrls>
</configuration>
</execution>
</executions>
<configuration>
<target>2.1</target>
<verbose>true</verbose>
</configuration>
</plugin>
<plugin>
<!--
Unjar the wsimport-client.jar created in the jaxws-maven-plugin to the WAR's classes folder
-->
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<phase>process-resources</phase>
<configuration>
<target>
<unzip src="${project.build.directory}/wsimport-client.jar" dest="${project.build.directory}/classes" />
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
taken from here: https://gist.github.com/mpellegrini/5439304

I had the same issue, and I had to unzip the created jars and re-zip in one single jar (so, putting the wsdl file from the inner jar in the final jar).
Thanks to peterh comment, I think I understood the "trick": in Maven output I can see a log like
jaxws:wsimport args: [..., -Xnocompile, -clientjar wsdl.jar, ...]
so the wsimport command is launched without compiling che code, and in fact a wsdl.jar is created in the target/classes folder.
I think wsimport is just generating the sources and the jar with the wsdl, then the compilation and the packaging is done in the following steps.

using maven coordinate style episodes in wsimport

I'm building (multiple) complex webservice with base XSD types from all kinds of standards (GML, SWE, XLINK, etc). Now, I would like to break up the compilation into more steps, preferrably one for each of the standards I'm using.
Advantages:
1) I can add create tooling libraries that I can re-use in all of my webservices on each of the standards.
2) I can make use of the power of JAXB2 basics plugin, which seems to work very nicely with the maven-jaxb2-plugin (org.jvnet.jaxb2.maven2) and create for instance interface bindings. This in contrast with the jaxws-maven-plugin plugin.
The final step would be using the org.jvnet.jax-ws-commons:maven-jaxb2-plugin to create the actual web service that I can implement in an EJB (or call as a client).
Now, the org.jvnet.jaxb2.maven2:maven-jaxb2-plugin plugin allows me to refer to episodes by means of their maven coordinate, as part of its like this:
<episodes>
<episode>
<groupId>org.example</groupId>
<artifactId>jaxb2-basics-test-episodes-a</artifactId>
</episode>
</episodes>
How can I do this by means of the org.jvnet.jax-ws-commons:maven-jaxb2-plugin? I've searched a lot, and experimented like this:
<plugin>
<groupId>org.jvnet.jax-ws-commons</groupId>
<artifactId>>maven-jaxb2-plugin</artifactId>
<version>2.1</version>
<executions>
<execution>
<goals>
<goal>wsimport</goal>
</goals>
</execution>
</executions>
<configuration>
<wsdlDirectory>src/main/resources/</wsdlDirectory>
<wsdlFiles>
<wsdlFile>example.wsdl</wsdlFile>
</wsdlFiles>
<xjcArgs>
<xjcArg>-b</xjcArg>
<xjcArg>../cpt-xsd/target/generated-sources/xjc/META-INF/sun-jaxb.episode</xjcArg>
</xjcArgs>
<verbose>true</verbose>
</configuration>
</plugin>
Which takes the episode file from the target dir of the (compiled) JAXB dependend project. This sometimes even fails in the maven build (why I did not figure out yet).
I've tried to use catalog files to make a mapping but (I think I saw somewhere a catalog mapping that took maven coordinates as destination), but haven't succeeded yet.

Are you aware of the OGC Schemas and Tools Project? (Disclaimer: I'm the author.)
Now, to your question. My guess would be that org.jvnet.jax-ws-commons:maven-jaxb2-plugin does not support the "Maven coordinates" as you call them. This was a feature I've specifically implemented for my org.jvnet.jaxb2.maven2:maven-jaxb2-plugin (disclaimer: I'm the author).
From the other hand, episode file is nothing but a JAXB binding file. So you can simply extract this file from the JAR artifact (for instance using the maven-dependency-plugin) and then include it more or less like you do it already. Just don't point to directories in other modules, this is not reliable.

Optimizing WSImport for Multiple WSDLs with Common Types

I am working on a fairly large WS project involving more than 20 different WebServices. These webservices, while independent from each other, share a sizable set of common types. We are using wsimport as an ant target in our build script to generate the proxy classes.
Problem:
As the number of our WS(and corresponding WSDLs) has increased, we noticed that the build times for our proxy classes has been climbing up pretty steep. Upon further investigation(and profiling), we found out that a huge chunk of the build time was being spent by wsimport on repeatedly generating the common types. It has gotten to a point that generating, compiling and packaging these proxy classes and their common types are taking around 15-20 mins. This is a problem for us and we are looking for ways to trim down the build time.
Question:
Is there a way to only generate the common types once? I've looked into some solutions found by googling. One involved writing a WSDL accumulator which parses the WSDLs and combines them into a single WSDL so wsimport is only called once. Another one hinted at using episode files but further investigation only yielded that there were problems with using that approach.
Note: I have seen some older similar questions but none of them had any answers.
wsimport multiple generated wsdl's
How can I tell wsimport that separate WSDL files are referring to the same object classes?

First of all I would use apache cxf to do that build as it can handle multiple WSDLs at the same time and is much more modern. It will be much more efficient and generate better classes. Second of all I would stop worrying about it unless the WSDL files are changing a lot. Instead i would put them into a separate artifact and build them once and then import them into the project as their own artifact. The only thing non-generated in that archive should be test code to test endpoints. As for the build, the Maven plugin config i have used with great success is pasted below.
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>${apache.cxf.version}</version>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<configuration>
<sourceRoot>${project.build.directory}/generated-sources/</sourceRoot>
<defaultOptions>
<catalog>${wsdlDir}/jax-ws-catalog.xml</catalog>
<bindingFiles>
<bindingFile>${wsdlDir}/jaxb-bindings.xml</bindingFile>
<bindingFile>${wsdlDir}/jaxws-bindings.xml</bindingFile>
</bindingFiles>
<noAddressBinding>true</noAddressBinding>
<extraargs>
<extraarg>-client</extraarg>
<extraarg>-xjc-Xbug671</extraarg>-->
<extraarg>-xjc-mark-generated</extraarg>
</extraargs>
</defaultOptions>
<wsdlOptions>
<wsdlOption>
<wsdl>${wsdlDir}/cis.wsdl</wsdl>
</wsdlOption>
</wsdlOptions>
</configuration>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.apache.cxf.xjcplugins</groupId>
<artifactId>cxf-xjc-bug671</artifactId>
<version>${apache.cxf.xjc.version}</version>
</dependency>
</dependencies>
</plugin>
This is set up to generate from only one WSDL but one could easily append more WSDLs and I have done so in other circumstances.

Using different package declarations in .java classes than their real file system locations, in Eclipse

I am currently developing a code generator, and I have built a test suite for it. The general ideia of how it is organized is depicted in the following image:
The Tests.java is a standard JUnit test class. I expect it to be on
package tests.system.bytecode.temp_tests;
as any Java developer would expect.
On the other hand, IOrderable.java and TreeSet.java are to be used by my code generator (after they are compiled to .class files, that is). But it is a bit troublesome for me to manage their current big big package declarations. The situation will only get worse as I add more tests and start to try to organize(nest) even more the tests.
It'd be perfect if IOrderable.java and TreeSet.java could have package declarations independent of their real paths, far removing future maintenance problems.
Is it possible to accomplish this with Eclipse? Maybe using Ant or Maven?
Thanks

Compiling .java classes in my Eclipse project with package declarations that don't correspond to their physical path in the project.
Should be not possible.
But you can separete the classes by different source folders.
In Eclipse you can have several source folders. When compiling they get mixed, so it would be what you need: one src folder for the normal classes and one src-gen Folder for the generated classes.
And with maven you can do the same.
There you have by default:
src/main/java
src/test/java
But you can add for example src/main/java2 or target/generated-src
Therefore you need the org.codehaus.mojo build-helper-maven-plugin. For example:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${basedir}/target/generated-src</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>