In a very big Java app with lot's of DTOs, I want to export to an external project only the DTOs that are relevant to REST calls, and even better to export a part of them (the minimum required for REST calls).
The project uses Swagger and I am wondering if it is possible to take the output of Swagger (uses Java DTOs to create JSON\YAML files), which have the exact content I need, as an input to generate new Java DTO files. The generated files will be only those needed for REST and I will be able to easily export them.
Is this possible?
If not, what is the best approach to do that?
Maybe check out swagger.generator.io where you can generate a whole client library (including DTO classes) for your specified swagger definition file. For documentation please refer to their github page. You can also do the generation of the API client locally utizing the swagger codegen tools.
Related
I am using the openapi-generator-maven-plugin to generate model sources.
Is there a way to generate them only with fields and without any access methods?
I want the access methods to be generated via lombok with the additionalModelTypeAnnotations configOption in the maven configuration of the openapi-generator-maven-plugin
You can implement those customizations by changing the Mustache templates
Fetch the templates of the Java framework (ie spring-boot) you want to use (ie openapi-generator-cli author template -g spring --additional-properties=library=spring-boot -o tmp/mytemplates
Modify the local model.mustache file to import the packages you want (lombok) and pojo.mustache to remove the getters/setters. There might other customisations necessary (each framework templates are different) but this the recommended approach.
As #beppe suggested in their answer, this can easily be done by modifying the mustache template. However, I highly advice against it. In doing so, you discard many of the the features included with the model objects created by the generator. Some of the features you lose are:
Bean Validation
Jackson Serialization Library Support
Support for vendor extensions
By adding the Lombok annotation to the generated files, you are basically ignoring the main point of the generator, which is to generate files that support each other. You are instead using a generator to call a generator.
Finally, the amount of customization necessary to make the lombok library work with the mustache files is much more than is really worth it. Sure, you can add #Data or #Jacksonized to your model, but what about #JsonIgnore? Do you want to use parameters in your Lombok calls? Because you can't set the builder classname via #Builder(builderClassName = "EmployeeBuilder"). That would be hardcoded. Instead, you'd have to use mustache parameters, such as #Builder(builderClassName = {{$builderClassName}}), which you'd then have to define elsewhere. What about #Builder vs #SuperBuilder? Which one do you use in which situation? How do you define and template it?
At this point, you might as well rewrite the entire pojo.mustache to be able to use the lombok annotations. But, what if you need the old pojo.mustache functionality elsewhere? Now you need to write a custom generator to determine which mustache to use in which situations.
It is best to just build the domain models as the openapi-generator intends and use them as they are. You can add annotations if you need to via vendor extensions such as x-field-extra-annotation and x-class-extra-annotation if you really feel the need to.
I am maintaining a Java application where we're constantly adding new features (changes in the api). I want to move towards using OpenAPI as a way to document the api. I see two schools of thought:
Write the code, use some annotations to generate the OpenAPI spec.
Write the OpenAPI, use it to generate some server code.
While both seem fine and dandy, the server code is simply stubbed out, and would then require a lot of manual plugging in of services. While that seems fine as a one time cost, then next time I update the interface, it seems to me the only two options are
Generate them all again, re-do all the manual wiring.
Hand edit the previously generated classes to match the new spec file (potentially introducing errors).
Am I correct with those options? If so, it seems that using the code to generate the api spec file is really the only sane choice.
I would recommend an API First approach where you describe your API in the yaml file and generate with each new addition.
Now how do you deal with generator overwriting manual work?
You could use inheritance to create models and controllers based on the code that is generated.
You can also use the .ignore file provided with the generator to if you want to be sure of files not being overwritten.
I have an existing project having java code for Rest Web Services. I integrated Swagger to the java project which in turn added lot of annotations and descriptions, messing up my existing code. Is there a way to integrate swagger and read values from another class instead of messing up my existing class?
You just need to add the following annotation with you java file:
#Api(value = "myAdmin", description = "Operation pertaining Admin UI")
Other things are taken care by the RestContoller and all byt itself.
This annotation is not at all messing up with your code.
Just a little background:
I have a wsdl and schema files with a lot of hierarchy, meaning there are a lot of import/include tags in the schema. I have a netbeans project and used wsimport to generate the client code. I’m successfully calling the web service operations and getting data.
What I need:
I'm looking to get access to the model the xjc compiler uses to generate the java code from the schema. I would like to do this without writing my own plugin if possible. I want to use this model to generate my own code with codemodel.
The question is:
Is there a way to get access (preferably from my client project described above) to the model or 'outline' without writing a xjc plugin?
I’m new to java and jaxb so any direction and detailed instructions are much appreciated.
You can invoke the xjc compiler directly by using Ant or Maven. Just point it at the schemas referenced. If you need some control over the code generated, you could look at custom binding in JAXB.
What exactly are you trying to accomplish?
I've inherited the code base for a Java application which talks to a few SOAP web services. Proxy classes to do this are generated using an ANT task calling wsdl2java. As my Java experience is quite limited, I'm still trying to get my head around exactly how this all works.
There is a build-wsdl2java.xml file in the project that seems to contain the configuration information required for the class generation. The file as it stands currently has attributes that aren't currently supported (namespacesmapfile, overWriteTypes, testcaseoverwrite), but if I attempt to resolve this by changing the first to 'namespacemappingfile' and removing the others, the attributes revert back if the project is cleaned. The URL for the WSDL also reverts back if it is changed.
What controls the generation of this file, and where do I define the configuration parameters that it contains?
Finally found out what was controlling this and, more importantly, have got things compiling again. I'm using JBuilder 2008 (an Eclipse based Java IDE from Embarcadero Technologies), and it would appear the client proxy classes were generated from the WSDL by using JBuilders built in support for this, which is effectively a wrapper for wsdl2java as mentioned by Noergaarde.
In order to set settings such as the URL for the WSDL, I had to switch to the Modeling perspective, and use the Model Navigator to change the URL, by selecting the class under the Web Service Client node and using the Properties view.
When you do a build of your project, does the timestamp of build-wsdl2java.xml change? ie. is this file generated by the build in another ant file?
At any rate, it certainly sounds like your client stubs are generated using AXIS.
http://ws.apache.org/axis/java/user-guide.html#WSDL2JavaBuildingStubsSkeletonsAndDataTypesFromWSDL