Closed dyanarose closed 6 years ago
Thank you for reporting this. Very nice with such a detailed description. I will take a look ASAP. The plugin actually has some integration tests which I had expected would also catch such classloading issues but apparently not. I am maintaining a similar Gradle plugin and there I have seen a similar issue relating to transitive dependencies of Swagger core jax-rs module having changed.
I have tried to reproduce this in a simple JAX-RS based project but I cannot seem to get this behaviour. My suspicion would be that this is something related to the Maven dependencies providing the JAX-RS annotations. Would it be possible for you to post the entire pom.xml
? I expect your project imports either java-ee-web-api
, javax.ws.rs-api
or similar - is that set to provided
scope in your project?
I'll get the pom to you by the end of the week (holiday 🙂 )
there are no dependencies marked as provided, no.
Pom can be seen at: https://gist.github.com/dyanarose/0925e6ae01e82e59f80a227debaef36c
That pom is set to Java 8 as I've been testing this, I get the same results with Java 10
Hard one to reproduce this one. Tried setting up at test project with the same dependencies but I still get an OpenAPI (Swagger) document with all the correct endpoints. I am wondering whether running Maven with "-X" would get any useful output but otherwise I am afraid we will have to see if we can create a simple project to reproducere this maybe taking the precise ‘pom.xml’ from your project just adding a single class with ‘@Path’ annotation.
I can understand why your dependencies are not scoped "provided" as you do not deploy in an application container but generate an executable jar - makes sense.
Hmmm, indeed. I'll get together a small sample project and stick it in a Dockerfile.
Could be environmental as well.
Well, I have managed to reproduce the error now. Seems there is some problem in how the plugin classpath is resolved. So in essence the classes of the Maven module itself is not exposed to the plugin.
I will look into the classpath setup of the plugin however I do have a workaround for you. If you add the project itself as dependency of the plugin it seems to generate the OpenAPI document.
<plugin>
<groupId>io.openapitools.swagger</groupId>
<artifactId>swagger-maven-plugin</artifactId>
<version>2.0.0</version>
<dependencies>
<dependency>
<groupId>com.salecycle</groupId>
<artifactId>dashboards-api</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
<configuration>
<resourcePackages>
<resourcePackage>com.salecycle.dashboardsapi.api</resourcePackage>
</resourcePackages>
<outputFormats>
<outputFormat>JSON</outputFormat>
<outputFormat>YAML</outputFormat>
</outputFormats>
<outputDirectory>target/api</outputDirectory>
<outputFilename>swagger</outputFilename>
</configuration>
<executions>
<execution>
<phase>compile</phase>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
</plugin>
👍 yup, confirmed that adding the dependency does the trick for now. Thanks for digging through with this.
Trying to use this with a project with swagger-core/swagger-jaxrs2 2.0.5 annotations.
I found the output to be missing every single api and only including the Info data from the plugin specification.
I've been debugging my way through this and I've found that when the Configuration Builder builds it doesn't include any of the URLs for the project, so it wouldn't be able to find any project classes under the listed resourcePackages.
I altered the plugin code to ensure that the plugin picks up the project URLs, and also had to set the config ClassLoaders.
This has then led to the project classes being loaded, but unfortunately I'm now at a dead end when a project class that very clearly is annotated with javax.ws.rs.Path (and it shows in the annotationData on reflection), responds to ReflectionUtils.getAnnotation(cls, javax.ws.rs.Path.class) with null.
Now, I assume I'm doing something quite wrong here (and I'm by no means a reflection guru) as my expectation is that the plugin would run during the build process, run over the classes found under the resourcePackages and an OAS 3.0 would come out the other side, similar to how the kongchen plugin works for OAS 2.0, but it doesn't seem to want to play ball for me.
Plugin configuration in case you're curious
(edits for language, too much reflection debugging seems to remove my ability to type)