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)

1.0.0.M18

• add @NotNull if nullable is default (i.e. true) and bean validation is enabled.

• openapi-processor/openapi-processor-core#20, the type mapping (v2 only) configuration allows to reference the target package-name in generic parameters using the {package-name} expression. This makes it possible to adjust the package-name without touching the mapping and it can reduce duplication if the mapping contains many generic parameters.

  openapi-processor-mapping: v2
  options:
    package-name: io.openapiprocessor.generated.model
  
  map:
    types:
      - type: FooPage => org.springframework.data.domain.Page<{package-name}.Foo>
  

• openapi-processor/openapi-processor-core#21, a primitive type with a custom format (not defined by the OpenAPI specification) did break processing. The processor does now ignore unknown custom formats. For example the following definition

  type: string
  format: unknown-custom-format
  

  will be processed as if it has no format at all:

  type: string
  

• openapi-processor/openapi-processor-core#22, mapping of primitive schemas did not work. It is now possible to have a primitive schema

  components:
    schemas:
      Foo:
        type: string
  

  and map this to a specific target java type:

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

• #23, parameter $ref's were not resolved when processing with the openapi4j parser.

• updated openapi-processor-core to 1.2.0 (was 1.1.1)

• updated openapi4j parser to 1.0.4 (was 1.0.3)