2021.6

#133, improved error reporting

Sometimes parsing errors of the OpenAPI description were not be properly reported (e.g. by the maven plugin). Parsing/validation errors are now handled and reported at the processor level and reporting no longer depends on the plugin that calls the processor (gradle/maven).

#134, nested oneOf & anyOf

if an oneOf/anyOf was used in a schema property the processor generated code that used a non-existing class as java type for the property.

dependency updates

• updated openapi-processor-core to 2021.6 (was 2021.5)
• updated swagger parser to 2.0.28 (was 2.0.27)

2021.5

openapi-processor/openapi-processor-core#68, improved response type handling

This is a breaking change because it changes the code that gets generated by default. To keep the old behavior set result-style in the mapping.yaml to all:

openapi-processor-mapping: v2

options:
  package-name: ...

map:
  result-style: all

See the core release notes for a detailed description of the change.

dependency updates

• updated openapi-processor-core to 2021.5, (was 2021.4)
• updated swagger parser to 2.0.27 (was 2.0.26)

2021.4

This release has several bug fixes and a couple of improvements for multipart requests and bean-validation. A new feature is the ability to automatically add a model-name-suffix to all generated model classes.

See the core release notes for all the details.

• updated openapi-processor-core to 2021.4, (was 2021.3.1)
• updated swagger parser to 2.0.26 (was 2.0.25)

2021.3.1

• #126, fixed duplicate media types in the produces parameter of the mapping annotation by updating to openapi-processor-core 2021.3.1.
• updated swagger parser to 2.0.25 (was 2.0.24)

2021.3

• improved javadoc generation. See core release notes for more.

• #124, fixed wrong schema name (i.e. class name) selection of a $ref-chain. See core release notes for more.

• update openapi-processor-core to 2021.3, (was 2021.2) See the core release notes for details.

2021.2

• endpoint http method mapping, limit endpoint mappings to a specific (get, post etc.) http method. See core release notes for more.

• nullable mapping, map nullable properties to jackson-databind-nullable for implementing json merge patch. See core release notes for more.

• update openapi-processor-core to 2021.2, (was 2021.1) See the core release notes for details.

2021.1

• jars are published on maven central (was jcenter).

• openapi-processor/openapi-processor-core#53, add @RequestParam annotation to mapped data types if the source OpenAPI type was a simple data type, i.e. integer, number, boolean or string.

  Background: the processor did not add annotations to mapped data types because Spring doesn't need (or allow) parameter annotations for model object (pojo) parameters. In case of a (simple data type) mapping like this:

  openapi-processor-mapping: v2
  
  map:
    types:
      - type: string:uuid => java.util.UUID
  

  this simple logic fails because it assumes that the source data type is an object data type. In case of a simple source data type Spring needs the @RequestParam annotation to bind it.

• updated openapi-processor-core to 2021.1 (was 2020.1). See the core release notes for details.

2020.1 (1.0.0)

• updated openapi-processor-core to 2020.4 with a couple of bug fixes and improvements.

1.0.0.M20

• openapi-processor/openapi-processor-core#30 (core), preserve the "?" generic parameter of a mapping and pass it on to the generated api, e.g. a mapping like

  map:
    paths:
      /foo:
        parameters:
          - add: foo => io.openapiprocessor.Foo<?>

  does now generate

  void foo(Foo<?> foo);

  instead of

  void foo(Foo foo);

• #119 (core), primitive type could match a primitive type with format mapping, e.g. with the mapping

  openapi-processor-spring: v2
  
  map:
    types:
      - type: string:binary => io.openapiprocessor.Foo
  

  it was possible that a primitive string was mapped to io.openapiprocessor.Foo instead of java.lang.String

• (core) a ref loop with array items caused a NullPointerException

• updated openapi-processor-core to 1.3.0 (was 1.2.1)

1.0.0.M19

• the internal representation of an empty response (ie. without any response data) leaked to the generated code. Visible by a produces = {"?"} in the mapping annotation and an Object return type of the endpoint.
• updated openapi-processor-core to 1.2.1 (was 1.2.0)