Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 17:45
    davidmigloz commented #12615
  • 17:44
    davidmigloz commented #12615
  • 17:42

    wing328 on gh-pages

    Deploy website version based on… (compare)

  • 16:08
    fredericrous commented #12715
  • 16:07
    fredericrous commented #12715
  • 16:04
    fredericrous commented #12715
  • 16:01
    fredericrous commented #12715
  • 15:48
    evanjmg opened #12715
  • 15:06
    welandaz labeled #12714
  • 15:06
    welandaz opened #12714
  • 14:20
    LubomirS edited #12713
  • 14:20
    LubomirS edited #12713
  • 14:20
    LubomirS edited #12713
  • 14:20
    LubomirS edited #12713
  • 14:19
    LubomirS edited #12713
  • 14:19
    LubomirS opened #12713
  • 14:00
    hnitzsche edited #12709
  • 13:59
    hnitzsche edited #12709
  • 13:35
    kain88-de commented #11770
  • 11:56
    starshinata edited #12712
YishTish
@YishTish
The test does not check for the content and structure of the response. I would like to add a test for responses, one that is out of the codegen's scope. The outcome will be 2 tests - one that should always pass, and one that will fail until the programmers add their business logic
If there's interest in the community, I can work on these tests a bit more, and pack them as a stand-alone module
Fjolnir-Dvorak
@Fjolnir-Dvorak
One thing I find astonishing: I am currently fixing the issue with camelcase reserved words once and for all. Half of the generators implemented this on their own just to get rid of the case insensitivity, but why didn't anyone add it as a feature to the BaseCodegen?
It seems it was broken all the time and no-one fixed it and just did their own
Jim Schubert
@jimschubert
Could also be that it's not a huge issue in practice. It should be done well, though.
A lot of what we're doing still is fixing up architectural and logical decisions from the swagger-codegen codebase. It's been slow, but the 4.x releases and intended to be a lot of these types of fixes.
I have documented a lot of my target here: https://github.com/OpenAPITools/openapi-generator/projects/5 I'm passing for 5.0 to have many of this work done (if not all of it).
I'm planning to do this one next: OpenAPITools/openapi-generator#840
Jim Schubert
@jimschubert
And I'd like to get OpenAPITools/openapi-generator#852 done by 4.2 so I have time to separate generator, workflow, template.
The idea there is to allow for generation from multiple spec types (not just OpenAPI). Core diagram is here: OpenAPITools/openapi-generator#845
Fjolnir-Dvorak
@Fjolnir-Dvorak
I got it sorted out finally, at least I think so. Some generators have no tests so I do not know if I repaired them as the original author intended. In total I had to touch every generator.
If you have a ticket you wish done I could look into that this weekend. We are using the generator at work so it is only fair to give something back
Nate Bross
@fuzzzerd
There are a few major bugs in the current 4.0.3 (that have fixes in master) for the typescript-fetch generator. When is the next scheduled patch release?
Nate Bross
@fuzzzerd
Specifically, around generating clients with single parameters, and Bearer authentication.
Fjolnir-Dvorak
@Fjolnir-Dvorak
@jimschubert to understand it correctly: Your intention is to migrate as much logic out of the individual generators or abstract classes into the base generator so each language has to implement less logic and that the general generation logic gets more powerfull?
Jim Schubert
@jimschubert
The idea is to move logic into reusable "workflow" instances, and move language specific data to reusable language settings providers. My plan is to have spec transformations occur outside of generators, passing an immutable standard into the generator, and allow the generator a single mutation before the workflow instance passes this object to a template.
As you can see from today's refactor, you've changed a single behavior in the workflow, but had to change it everywhere. I want to get to a point where we change it in one place.
Michal Foksa
@MichalFoksa
Hellou! I have create #3476 to document Mustache lambdas registered in DefaultCodegen. It is simple PR.
Fjolnir-Dvorak
@Fjolnir-Dvorak
I also noticed that every method and property is protected. I changed that to private in my pull request to make it clear that those fields should not be used and in hope that a future change / fix will be made in the base method and not on a language base. Those are the first private values in the baseclass so I do not know for sure if that is declared as an antipattern or not in this project.
If private fields are allowed I would be happy to leave it as it is, if not, well, I guess I would change it then.
John Wang
@grokify

What's the latest status on Handlebars support?

Are we good to start building out template sets in handlebars to ship with the OAG?

I saw that this PR was merged a while back:

OpenAPITools/openapi-generator#2657

Jim Schubert
@jimschubert
@grokify from the README: "Embedded templates are only supported in Mustache format. Support for all other formats is experimental and subject to change at any time.” (https://github.com/openapitools/openapi-generator#template-creator)
We’re not planning on allowing non-Mustache templates shipped with oag until we have significant improvments on architecture. Namely, we’ve discussed a testable object instance/interface which is passed to templates rather than a Map<String, Object> with an undefined structure. We’re also looking to separate template logic from generation logic so we don’t need to have a method in a base type that requires knowledge of the template engine in order to monkey patch it’s compiler.
KimJohn Quinn
@kjq

Hello everyone. We have been switching over to your OpenAPI generator and finally after quite some time things are looking pretty good. It is generating for the most part spring, javascript, python, and dotnet clients reasonably well. I have a couple of questions, hopefully this is the place to ask but if not please direct me to where, about generation with OpenAPI annotations originating from Java CXF + Reactor endpoints...

I have an endpoint like below:
1) How do I represent the multipart request properly?
2) The query params, if they have a @Default, are rendered as 2 different parameters.

Any help would be appreciated.

    @POST
    @Produces(APPLICATION_JSON)
    @Consumes(MULTIPART_FORM_DATA)
    @Operation(
        operationId = "uploadToS3",
        summary = "Upload files",
        description = "Upload files to S3",
        parameters = {
            @Parameter(name = "client", description = "Client name", required = true),
            @Parameter(name = "project", description = "Project name", required = true),
            @Parameter(name = "unique", description = "Use unique names", in = QUERY)},
        requestBody = @RequestBody(
            content = @Content(
                mediaType = MULTIPART_FORM_DATA,
                schema = @Schema(type = "string", format = "binary"),
                encoding = @Encoding(
                    name = "file",
                    contentType = APPLICATION_OCTET_STREAM))),
        responses = {
            @ApiResponse(
                responseCode = "200",
                description = "The uploaded files",
                content = @Content(
                    array = @ArraySchema(
                        schema = @Schema(implementation = FileResult.class))))})
      public Flux<FileResult> uploadFiles(@PathParam("client") String client,
                                        @PathParam("project") String project,
                                        @QueryParam("unique") @DefaultValue("false") boolean unique,
                                        @Context HttpServletRequest request)

BTW: In the csharp-dotnetcore template we had to adjust the use of value in the query param iterator because it conflicted with variables named the same. Seems just giving it a more obscure name would prevent the collision against something that could be a common property name.

Jim Schubert
@jimschubert
@kjq can you provide more details about the dotnetcore issue? We may need an escape or extract some logic to a method.
KimJohn Quinn
@kjq

@jimschubert - it was these blocks specifically in the api.mustache. The inner value conflicted with a parameter type that happened to be named value as well. You can see where I just renamed the inner var value to v to solve my issue for now.

 foreach (var kvp in {{packageName}}.Client.ClientUtils.ParameterToMultiMap("{{#collectionFormat}}{{collectionFormat}}{{/collectionFormat}}", "{{baseName}}", {{paramName}}))
                {
                    foreach (var v in kvp.Value)
                    {
                        requestOptions.QueryParameters.Add(kvp.Key, v);
                    }
                }

Also, for what it is worth here are some other things I ran into which may or may not of been my usage:

  1. In the typescript-angularMaven POM configuration it seemed that when I added models for the <modelPackage> it munged the package. I had to explicitly set it to model for the value and it worked. Without it, it seemed to produce an odd models.model or something of the sorts I can't remember.
  2. In the Java generated POMs, there were simpler dependency setups that could be used, especially with the Spring ones. Out of the box, none of them compiled for me though. In this case, I had my own parent POM to apply but it really carried over some Spring BOM ones which cleaned up the POM.
  3. Python seemed to work out-of-the-box though I have not tested it yet. I briefly tested the Java+Jersey one and it worked for the methods I tried.
KimJohn Quinn
@kjq

Just responding to my own questions above:

1) The "duplicate" parameters only occur when I had the in property on the annotations. It doubled up with the JAX-RS annotation and looked to treat them as individual parameters. I know there are some rules mentioned to what takes precedence but removing the in property from the annotation in the @Operation solved the issue for me.

2) I "think" I have the multiple-file/multipart upload working using something like this below. At least code-wise and in Swagger UI it gets acknowledged as a multiple file upload.

@POST
    @Path("/uploads")
    @Produces(APPLICATION_JSON)
    @Consumes(MULTIPART_FORM_DATA)
    @Operation(
        operationId = "uploadFilesExample",
        summary = "Upload files",
        description = "Upload files",
        parameters = {
            @Parameter(name = "client", description = "Client name", required = true),
            @Parameter(name = "project", description = "Project name", required = true),
            @Parameter(name = "unique", description = "Use unique names")},
        requestBody = @RequestBody(
            content = @Content(
                mediaType = "multipart/form-data",
                schema = @Schema(implementation = MultiRequest.class),
                encoding = @Encoding(
                    name = "file",
                    contentType = "application/pdf, image/png"))),
        responses = {
            @ApiResponse(
                responseCode = "200",
                description = "The uploaded files",
                content = @Content(
                    array = @ArraySchema(
                        schema = @Schema(implementation = FileResult.class)))),
            @ApiResponse(responseCode = "400", description = "Bad request"),
            @ApiResponse(responseCode = "401", description = "Unauthorized"),
            @ApiResponse(responseCode = "403", description = "Forbidden"),
            @ApiResponse(responseCode = "409", description = "Version Conflict"),
            @ApiResponse(responseCode = "500", description = "Backend Error")})
    @PreAuthorize("isSecured(#client, 'projects', 'write')")
    public Flux<FileResult> uploadFiles(@PathParam("client") String client,
                                        @PathParam("project") String project,
                                        @QueryParam("unique") @DefaultValue("false") boolean unique,
                                        @Parameter(hidden = true) @Context HttpServletRequest request)
    {
        return null;
    }

    class MultiRequest
    {
        @ArraySchema(
            schema = @Schema(type = "string", format = "binary", description = "image file"))
        public List<String> file;
    }
William Cheng
@wing328
We've added a OCaml client generator: https://twitter.com/oas_generator/status/1155676626954276864
Please give it a try and help us spread the awesome work of this community
John Wang
@grokify

We’re not planning on allowing non-Mustache templates shipped with oag until we have significant improvments on architecture. Namely, we’ve discussed a testable object instance/interface which is passed to templates rather than a Map<String, Object> with an undefined structure. We’re also looking to separate template logic from generation logic so we don’t need to have a method in a base type that requires knowledge of the template engine in order to monkey patch it’s compiler.

Thanks for the update. Are these changes being planned for 5.0?

GazEdge
@GazEdge
hey - im looking for a dev workflow/process to use swagger with js frontend - any decent blog posts anyone can recommend?
YishTish
@YishTish
@GazEdge - I worked on a project where we used codegen to generate server-side and client-side code as a boilerplate
the front-end was Angular
and back-end was JS
I'm working now on generating a NodeJS codebase for OpenAPI 3
GazEdge
@GazEdge
@YishTish yeah that’s pretty much my exact use case - js backend and vue.js front. Trying to work out how I can use the OpenAPI spec to create boilerplate for front and backend, as well as supporting any testing. Was hoping there may be some nice blog post series on it. Don’t have the bandwidth to work it out from scratch.
YishTish
@YishTish
@GazEdge - I don't know which output languages are available. Once you have the openapi-generator working on your computer (there are many ways to get it working, PM me if you need a walkthrough of that), you can type openapi-generator and get a list of available outputs. Then, run openapi-generator generate -i {{path to your openapi.yaml/json file}} -l {{language you want to generate, based on the list retrieved earlier}} -o {{directory where the generated code should be written}}. If all goes well, you should have all you need to start your project. Go through the files that were generated and get a feel of your environment. It should be pretty self-explanatory.
I'm working on a nodejs-express generator. Still work in progress. If you want to see what I've done so far, please let me know.
Michal Foksa
@MichalFoksa
Hellou,
I have a following openapi definition, it is a fragment got by -DdebugOpenAPI. I would like to know how to access x-summary and x-description field in mustache template?
[main] INFO  o.o.codegen.DefaultGenerator - OpenAPI Generator: openapi-yaml (documentation)
[main] INFO  o.o.codegen.DefaultGenerator - Generator 'openapi-yaml' is considered stable.
{
  "openapi" : "3.0.0",
  "info" : {
    "title" : "My Microservice API",
    "description" : "......",
    "termsOfService" : "http://sam.adidas.com/ts",
    "license" : {
      "name" : "Proprietary",

    },
    "version" : "1.2.0"
  },
  "servers" : [ {....
  } ],
  "paths" : {
    "/users" : {
      "x-summary" : "Users Collection",
      "x-description" : "Retrieve user infomation"
      "get" : {
        "tags" : [ "users" ],
        "summary" : "find",
        "description" : ...",
        "operationId" : "findUsers",
        "parameters" : [ {...} ],
        "responses" : {....},
      }
Is it even accessible ?
Stefan Dresselhaus
@Drezil
@GazEdge if you want great mock-servers you should use the haskell-backend... :)
We have some mocking laying around here - and it even gets easier with deriving via .. so in about 5min-1h you can have a full generated json-mock-server up & running.. even with domain-specific data..
I think i have to write a blogpost or so about that .. :/
@Fjolnir-Dvorak did some work on that with me .. ;)
Jim Schubert
@jimschubert
@Drezil feel free to contribute a blog post (website/blog) ;)
William Cheng
@wing328
@MichalFoksa can you try {{vendorExtensions.x-summary}} inside {{#operation}} ... {{/operation}} ?
Michal Foksa
@MichalFoksa
@wing328 Thank you for hint, but ... these extension attributes are on path level (one level above operation)
@wing328 Woudl it make sense to add vendorExtension also to that level ?
Jérémie Bresson
@jmini
Does it work if you put them under operation?
William Cheng
@wing328
@MichalFoksa right, I see your point. we may need to update the code to handle that as I don't recall adding vendor extension support to the path level
Michal Foksa
@MichalFoksa
@jmini They are supposed to describe the path - without operation
Jérémie Bresson
@jmini
If yes, I think we should copy all the path from a vendor specific extension from path to each operation (because in the codegen layer for the template, there is no distinction anymore between path and operation)
we do this already if you define a parameter in "path".
Then you have them in each of the operation defined under this path.