[AVRO] Fix the package handling for the avro generator

[Choobz]

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\. If contributing template-only or documentation-only changes which will change sample output, be sure to build the project first.
• Filed the PR against the correct branch: master, 4.1.x, 5.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

@sgadouar @wing328

Description of the PR

Fix the issue 3987
Also fix an issue with the outputFolder that wasn't overridable through opts

[auto-labeler]

👍 Thanks for opening this issue!
🏷 I have applied any labels matching special text in your issue.

The team will review the labels and make any necessary changes.

[Choobz]

There's an issue with the inlined objects while generating the samples (avro-petstore.sh). That bug was already present on master. It doesn't correctly put the model.File in InlineObject1 for some reasons. Is it a known bug ?

[sgadouar]

Tkanks for this fix

[wing328]

That bug was already present on master. It doesn't correctly put the model.File in InlineObject1 for some reasons. Is it a known bug ?

Please open an issue with the details so that I can help take a look.

[wing328]

Do we need to remove the comma after "null"?

[Choobz]

That's the bug. It's supposed to be "type": ["null", "model.File"] after the generation by avro-petstore.sh.

Since the result is the same with master, it's another modification that broke it between MR 3728 and today.

The petstore.yaml in question :

'/pet/{petId}/uploadImage':
    post:
      tags:
        - pet
      summary: uploads an image
      description: ''
      operationId: uploadFile
      parameters:
        - name: petId
          in: path
          description: ID of pet to update
          required: true
          schema:
            type: integer
            format: int64
      responses:
        '200':
          description: successful operation
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ApiResponse'
      security:
        - petstore_auth:
            - 'write:pets'
            - 'read:pets'
      requestBody:
        content:
          multipart/form-data:
            schema:
              type: object
              properties:
                additionalMetadata:
                  description: Additional data to pass to server
                  type: string
                file:
                  description: file to upload
                  type: string
                  format: binary

And for some reasons, that one (which is pretty much the same) works :

 post:
      tags:
        - pet
      summary: Updates a pet in the store with form data
      description: ''
      operationId: updatePetWithForm
      parameters:
        - name: petId
          in: path
          description: ID of pet that needs to be updated
          required: true
          schema:
            type: integer
            format: int64
      responses:
        '405':
          description: Invalid input
      security:
        - petstore_auth:
            - 'write:pets'
            - 'read:pets'
      requestBody:
        content:
          application/x-www-form-urlencoded:
            schema:
              type: object
              properties:
                name:
                  description: Updated name of the pet
                  type: string
                status:
                  description: Updated status of the pet
                  type: string

The only difference that makes sense is the content type and the format field.
It seems like the form-data field has seen some update and for some reason it can't default back to just the basic string type.

I've crossed check with the jax-rs-cxf implementation and they have a specific mustache for it.

[wing328]

I think I know where to fix it. Will merge this PR and file another PR to fix it.

[wing328]

Also fix an issue with the outputFolder that wasn't overridable through opts

Can you please elaborate on that?

The line you removed seems to be common across all generators.

[Choobz]

Would my answer be enough for a bug report ?

[Choobz]

I did some more test on OuputFolder and I was wrong about it, it wasn't my problem with destination path. I reverted that part.