I'm attempting to create a prototype (using Grails 2) where we take advantage of swagger for our documentation.
As such, I had included the following in our BuildConfig.groovy:
compile "io.swagger:swagger-core:1.5.3"
compile "io.swagger:swagger-jaxrs:1.5.3"
And then I declared a bean in resources.groovy using the BeanConfig class provided by the above dependencies. And finally, I had just used the various annotations provided by the jaxrs dependency to document the controllers and their methods.
Everything was great until I realized that these are the older versions of swagger (as in, not OAS 3). I'm completely stumped as to how to use the new libraries.
Going through the documentation, I can pull in the dependencies like this in resources.groovy:
compile "io.swagger.core.v3:swagger-core:2.0.5"
But I have no idea what class I can use to initialize swagger. Where do I defined which packages it needs to scan? What class can I use to generate the swagger JSON?
I realize that there are plugins (like swaggydoc) but these are not maintained, and thus I would rather not use them.
Ideally, I would use the libraries provided by swagger themselves.
It's all just java code, and so I feel like I should be able integrate it with grails 2, especially since it worked with the old swagger libraries. But I need some help getting started.
Related
I know that there is a way to generate the client-side code from the swagger yaml with swagger-codegen, but is there a way to generate the swagger yaml with the C++ annotations similar to what can be done in Java.
There seem to be annotation libraries available for other languages e.g python C# (https://swagger.io/blog/api-development/swagger-annotation-libraries/) but I am not able to find any support for C++.
I don`t think so. As far as I know the Swagger Core Annotations are part of the Swagger Core Project, and in the documentation you can find:
Swagger Core is a Java implementation of the OpenAPI Specification.
Current version supports JAX-RS2.
Also the Prerequisites says:
You need the following installed and available in your $PATH:
Java 8
Apache maven 3.0.4 or greater
Jackson 2.4.5 or greater
Update:
I'm not quite sure if oatpp-swagger can fit your requirements.
I have a simple Dropwizard application with swagger integrated and I want to access the JSON created by swagger at compile time using Dropwizard Testing. Is this possible, and If it is, please guide me how it can be done?
I assume you use swagger-core for the generation of your Swagger spec. Swagger-core is a runtime library and produces the documentation as part of your running application.
There is a community contribution of a maven plugin that you can use to generate static documentation during the build process. Keep in mind that it may differ from the output of swagger-core as it basically scans the annotations but does not necessarily employ the same business logic of the generation process.
I would like to define my objects in a JSON file, and then instantiate them using Typhoon. Is this currently possible with Typhoon? I've downloaded the code from github, and looked through the code and docs, but I don't see a way.
Thanks in advance!
Since Typhoon 2.0 we only support the native format (recommended) along with auto-wiring macros. The main benefits are:
IDE refactoring and code-completion works without any additional plugins
No "magic strings" when wiring by reference.
Components can be resolved using the assembly interface. Since version 2.0 this includes supplying runtime arguments along with static dependencies.
In version 1.x, we supported XML along with the above styles, however it was not at all a popular feature. The main (valid) criticisms were that XML doesn't support the above benefits of the native style. This along with there being some overheads in maintenance lead us to decide to discontinue support in version 2.0.
There was one benefit - the ability to define assemblies at runtime. The closest thing that we have at the moment is Typhoon Config, which allows defining configurations in a text file.
Proceeding with JSON:
It would be quite simple to define a JSON parser.
Create a similar class to v1.8.2's XML parser.
Register the components from the parser. Either manually or by creating a TyphoonComponentFactory sub-class.
Unless you have a strong reason for using JSON, we recommend the native style.
In Eclipse, I'm using the already packed ij.jar instead of the source code. I added the ij.jar file as an external jar in Eclipse. Every plugin shipped in the original ij.jar works fine after I imported from ij.
Currently, I'm trying to use functions in the third-party plugin StackReg. Does anyone know how I can import the classes inside StackReg? I've tried to add StackReg_.jar as an external jar. However, this does not work.
From quickly looking at the source of StackReg plugin, I see that the classes are in the default package. In java, importing classes from default package to a named package is not possible without using reflection.
Possible solutions are:
Put your classes in the default package. Then you can use the classes in the default package without importing them. Note that using default package is bad practice in java.
Use reflection: https://stackoverflow.com/a/561183/1903534
Alter the StackReg plugin to not use the default package. But this might not be compatible with its license and your solution will not be compatible with the original jar.
How come it is good practice within Grails to place classes in packages (e.g. mycompany.Book)?
I know it is a prerequisite in order to deploy Grails solution to the Google App Engine (using the plugin), but other than that and a well structured code library for large projects, what other benefits are there in describing packages for classes within Grails?
Another good reason, as mentioned by Marcel Overdijk in this blog post, is if domain classes has the same name as classes within Groovy, it is not possible to distinguish the two.
Grails runs on Groovy, which has a strong heritage with Java. Java encourages packages for well-documented reasons and Groovy/Grails follows suit. I think the main benefit stems from your description: a well-structured code library for large projects.
The most valuable reason that I've seen, is that you cannot "import" classes without a package into a class that DOES have a package. that means that you can't access any domain/service/controller/etc classes that don't have packages from your utility code that you might put a package on.