I have a swagger object, and everything is working great. I have now come to the point that I need to add something like:
components:
schemas:
MyObj:
type: object
properties:
myExistingProperties.....
newProperty:
type: object
$ref: my.sf.package.MyNewClass
My question is how can I reference a concrete object from swagger yml?
Thanks,
Brian
I found the answer here:
Swagger Codegen use existing class
in the yml
components:
schemas:
MyObj:
type: object
properties:
myExistingProperties.....
newProperty:
$ref: '#/components/schemas/myNewobject'
in the pom:
<plugin>
<groupId>io.swagger</groupId>
<artifactId>swagger-codegen-maven-plugin</artifactId>
<version>2.2.2-SNAPSHOT</version>
<executions>
<execution>
...
<configuration>
...
<configOptions>
<import-mappings>MyNewClass=some.package.MyNewClass</import-mappings>
</configOptions>
</configuration>
</execution>
</executions>
</plugin>
Related
I am working on custom codegen using maven openapi generator plugin. I created a custom code generator project which has one java class named CustomCodegen.java with extends SpringCodegen and I have overridden the processOpts method where I added a new .mustache file which will be generated as *Exception.java class.
package com.swagger.blog.codegen;
public class CustomCodegen extends SpringCodegen {
#Override
public void processOpts() {
apiTemplateFiles.put("emptyinputexception.mustache", "Exception.java");}
#Override
public String getName() {
return "custom";
}
I have registered a service under src/main/resources/META-INF/services and created a file named
org.openapitools.codegen.CodegenConfig with content com.
swagger.blog.codegen.CustomCodegen(class which has the code). The name of the jar is swagger-codegen.
<groupId>com.swagger.blog</groupId>
<artifactId>swagger-codegen</artifactId>
<version>1.0.0-SNAPSHOT</version>
Now I want to use this custom generator on my other project and create a stub out of it. As shown on the code block below, I have used "custom" as the generatorName from the name we set on the CustomCodegen class and the custom generator dependency is used on the dependencies section of the open api generator plugin. I did mvn clean install to generate stub out of it. But when i do mvn clean install i get an error--> "Exception in thread "main" java.util.ServiceConfigurationError: org.openapitools.codegen.CodegenConfig: Provider com.swagger.blog.codegen.CustomCodegen not found". I can only find one topic on similar error on internet https://github.com/swagger-api/swagger-codegen/issues/7518. Can someone help with this or provide a github repo with similar custom code generator or sample project please Thanks for taking time to read this. Any suggestions will be greatly appretiated. The openapi generator plugin looks like this:
<plugin>
<groupId>org.openapitools</groupId>
<artifactId>openapi-generator-maven-plugin</artifactId>
<!-- RELEASE_VERSION -->
<version>6.0.0</version>
<!-- /RELEASE_VERSION -->
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<!-- specify the OpenAPI spec -->
<inputSpec>${project.basedir}/src/main/resources/openapi.json</inputSpec>
<!-- target to generate java client code -->
<generatorName>custom</generatorName>
<!-- override the default library to jersey2 -->
<library>spring-boot</library>
<output>${project.build.directory}/generated-sources</output>
<templateDirectory>${project.basedir}/templates</templateDirectory>
<configOptions>
<dateLibrary>java8</dateLibrary>
<sourceFolder>main/java</sourceFolder>
<artifactId>hi</artifactId>
<groupId>swaggerhub</groupId>
<basePackage>com.something</basePackage>
<invokerPackage>com.something</invokerPackage>
<configPackage>com.something.config</configPackage>
<modelPackage>com.something.model</modelPackage>
<apiPackage>com.something.api</apiPackage>
</configOptions>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>com.swagger.blog</groupId>
<artifactId>swagger-codegen</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>
</dependencies>
</plugin>
I create an OData client from an EDMX file using com.sap.cloud.sdk.datamodel.odata-core
(https://sap.github.io/cloud-sdk/docs/java/features/odata/generate-typed-odata-v2-and-v4-client-for-java).
My EDMX file contains the properties with sap:quickinfo values like
<Property Name="NAME" sap:label="C-Name" sap:heading="CUST" sap:quickinfo="Customer Name" [...] >
The generated fields looks like this
#SerializedName("NAME")
#JsonProperty("NAME")
#Nullable
#ODataField(odataName = "NAME")
private String nAME;
and I need an additional annotation like #Quickinfo("Customer Name").
Is there any way I can get this quickinfo mapped into an annotation to the generated entity?
I use this parameters for the generator:
<plugin>
<groupId>com.sap.cloud.sdk.datamodel</groupId>
<artifactId>odata-generator-maven-plugin</artifactId>
<version>3.52.0</version>
<executions>
<execution>
<id>generate-consumption</id>
<phase>generate-sources</phase>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<inputDirectory>${project.basedir}/sap/</inputDirectory>
<outputDirectory>${project.build.directory}/generated-sources/sap/</outputDirectory>
<deleteOutputDirectory>true</deleteOutputDirectory>
<packageName>app.customers</packageName>
<defaultBasePath>sap/opu/odata/SAP/</defaultBasePath>
<compileScope>COMPILE</compileScope>
<serviceMethodsPerEntitySet>false</serviceMethodsPerEntitySet>
<nameSource>NAME</nameSource>
</configuration>
</execution>
</executions>
</plugin>
Disclaimer:
I'm a member of the SAP Cloud SDK for Java development team.
The SAP Cloud SDK's OpenApi generator is a wrapper of the open source OpenApi Generator (we are using version 5.0.0-beta3).
Therefore, our wrapper supports only features that are also supported by the mentioned open source variant.
Unfortunately, creating arbitrary Attribute classes for properties of the service specification is not a supported feature as of now.
We are using OpenAPI and openapi-generator-maven-plugin with Spring Boot. We're trying to create an example object in our response. We've followed the suggestions of a number of different web pages, especially this one:
https://swagger.io/docs/specification/adding-examples/
But no matter what we try, we either can't get the example data to show up, or it gives us a compile error.
For instance, this seems to be what we should be using, from the doc we've seen:
patch:
tags:
- Color
operationId: testing
description: test
responses:
'200':
description: Return existing colors in a season
content:
application/json:
schema:
type: object
properties:
testName:
type: string
example:
testname: amy
But this is causing compile errors in the generated code for the API:
ApiUtil.setExampleResponse(request, "application/json", "\"{\\"testname\\":\\"amy\\"}\"");
There are too many escape characters in the code above, there should not be double escapes.
Here is the plugin config from our POM:
<plugin>
<groupId>org.openapitools</groupId>
<artifactId>openapi-generator-maven-plugin</artifactId>
<version>4.0.0</version>
<executions>
<execution>
<id>FlexPLM-ACL</id>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<inputSpec>${project.basedir}/apis/flexplm-acl.yml</inputSpec>
<generatorName>spring</generatorName>
<apiPackage>com.dcsg.pdcomm.flexplmacl.api</apiPackage>
<!-- Both of these APIs use the exact same DTOs, so we have put them into the same package -->
<modelPackage>com.dcsg.pdcomm.flexplm.dto</modelPackage>
<modelNameSuffix>DTO</modelNameSuffix>
<supportingFilesToGenerate>ApiUtil.java</supportingFilesToGenerate>
<configOptions>
<library>spring-boot</library>
<dateLibrary>java8</dateLibrary>
<java8>true</java8>
<interfaceOnly>true</interfaceOnly>
</configOptions>
<output>${project.build.directory}/generated-sources</output>
</configuration>
</execution>
</executions>
</plugin>
We've tried all different combinations of quoting and indentation, but to no avail. Please help us!
I am generating Java 8 code from yaml file specifying my REST API. Models generated with some swagger annotations that I want to get rid of. Is it possible somehow? And maybe it will be possible in the nearest future ?
Rest models will be traveling through Camle routes, so I would like to use jaxrs annotations if any..
I am using openapi 3.0.0 version, so I have to use newest swagger maven codegen plugin (which I find 3.0.0-rc1 in maven repository)
I just don't want to have swagger specific annotations in classes. I used:
<generateModelDocumentation>false</generateModelDocumentation>
The generated model:
import io.swagger.annotations.ApiModel; //THIS IS NOT COMPILING and i dont need annotated models, just simple pojo classes or maybe some jaxb annotations instead swagger specific..
import io.swagger.annotations.ApiModelProperty;
/**
* The requested data to the service.
*/#ApiModel(description = "The requested data to the service.")
#javax.annotation.Generated(value = "io.swagger.codegen.languages.java.JavaClientCodegen", date = "*****")
public class MyCustomRequest {
........
}
The pom.xml plugin:
<plugin>
<groupId>io.swagger</groupId>
<artifactId>swagger-codegen-maven-plugin</artifactId>
<version>3.0.0-rc1</version>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<inputSpec>${project.basedir}/swagger/MyCustomSpecification.yaml</inputSpec>
<language>java</language>
<configOptions>
<dateLibrary>java8</dateLibrary>
<java8>true</java8>
<interfaceOnly>true</interfaceOnly>
<useJaxbAnnotations>false</useJaxbAnnotations>
</configOptions>
<generateApis>false</generateApis>
<generateApiTests>false</generateApiTests>
<generateModelTests>false</generateModelTests>
<generateModelDocumentation>false</generateModelDocumentation>
<generateSupportingFiles>false</generateSupportingFiles>
<generateApiDocumentation>false</generateApiDocumentation>
<modelPackage>${project.groupId}.swagger.model</modelPackage>
<apiPackage>${project.groupId}.swagger.api</apiPackage>
<invokerPackage>${project.groupId}.swagger.invoker</invokerPackage>
<library>resttemplate</library>
</configuration>
</execution>
</executions>
</plugin>
With the cobertura-maven-plugin setters and getters can be excluded from code coverage using the ignoreTrivial option. Is there also such a possibility with the jacoco-maven-plugin?
This is my current configuration:
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.7.1.201405082137</version>
<configuration>
<excludes>
<exclude>com/welovecoding/web/blog/test/**/*.class</exclude>
</excludes>
</configuration>
<executions>
<execution>
<id>amend-unit-test-java-agent-option</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>report</id>
<phase>prepare-package</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
</executions>
</plugin>
From JaCoCo 0.8.0, it is possible to exclude the getters / setters (and also toString(), equals(), ...) automatically generated by Lombok from the coverage metrics thanks to filtering options :
Lombok
Methods annotated with #lombok.Generated (generated by Lombok getters, setters, equals, hashcode, toString, etc) - Done in 0.8.0
To that end, you will first need to create a lombok.config file located for example at the root folder of your projet, with the following contents :
lombok.addLombokGeneratedAnnotation = true
The #Generated annotation will be added to the setters / getters, etc. and will be skipped in the coverage analysis.
Not supported officialy, see comments in :
https://github.com/jacoco/jacoco/issues/15
mentioned solution:
It's a long time since this issue is opened. It a really interesting feature. For instance it's implemented in clover and corbetura. There are fork that implement filtering :
github.com/huangxiwei/jacoco ,
https://github.com/mchr3k/jacoco since the begining of the year. Why don't you merge those fork into master branch ? Even if all filtering is not implemented at start, main filters needed are listed in the wiki page you have written (Try with resources, sync block, enum static methods). Coverage is a very useful tool, more it's accruate more it's will be usefull. It helps alot when coverage reach a high value, it helps to focus on the right classes.
I recommend to use Cobertura that does not have such limitation and also does not have so many false positive warnings.