v0.2.4 Composed Types Part 1

This release includes the first step towards implementing ADR 0002, support for composed schema. The generator now creates a fluent builder API for constructing models which consumes every property defined on a schema or any of its components (i.e. allOf, anyOf, or oneOf schema). It also adds getter methods to each model that will return a type or an optional describing a type depending on whether the associated property is "mandatory" or not (i.e. both required and not nullable). Whether a property is mandatory is based on required and nullable keywords from component schema, and to the best of my knowledge is completely supported.

Other features of the Composed Types milestone (milestone 8) are not yet implemented, but this is a significant amount of work on its own and provides a lot of basic functionality, so it is released.

v0.2.3 - Graceful Exit for Candlepin

This release implements graceful exit from code generation when certain unsupported schema keywords are used (such as oneOf, anyOf, allOf, or not). This also adds object inference (for when OAS authors imply type: object but do not write it explicitly) and fixes a defect whereby Lily could not deserialize List responses.

Our work on graceful exit concentrated on those issues encountered while generating the (Candlepin)[https://github.com/candlepin/candlepin] OpenAPI specification. We may revisit this issue in the future, but this release is a significant step towards better incremental development support.

v0.2.2 Header parameter support

This release adds support for header parameters:

myApi.everyOperaton()
  .myOperation()
  .headers(headers -> headers.xMyHeader("foo"))
  .sendSync();

Every parameter declared by the API may be configured using the .headers() API. For any other headers, the user must set them via the java.net.http API directly.

v0.2.1 - Request Body Support

This release adds support for request bodies:

myApi
  .petsOperations()
  .createPet()
  .body(new Pet("Fido", 14)) // <--
  .sendSync();

Request body models are generated when the schema uses either an in-line definition or a #/components/schemas/ reference. We do not yet support #/components/requestBodies/ references.

Only application/json request body schema are processed into models, since we do not support other content types.

Whenever an operation supports sending request bodies, it always sets the content-type: application/json header. This is true even if no body is actually attached.

v0.2.0 Cleanup and address conflicting names

This release addresses edge cases in how we chose to generate and name API methods. The major changes are as follows:

• The JacksonBodyHandler has been removed. We now favor using the BodyHandlers.ofInputStream handler instead, which lets us lazily deserialize responses and gracefully handle deserialization errors.
• The "otherOperations" and "allOperations" operation groups are now the "everyUntaggedOperation" and "everyOperation" groups. This avoids problems created when a specification uses the "all" and "other" tags.
• Most importantly, parameters are no longer configured directly on the operation API. Previously, if an API specified two parameters named "foo" in different locations like the path and query (which is valid), Lily would try to define a single foo(...) setter on the operation and fail. Because parameters are unique by name and location, we now configure parameters based on their location using callbacks:

var response = api
  .everyOperation()
  .doAThing()
  .path(path -> path
      .id("1234"))
  .query(query -> query
      .foo("foo")
      .bar("bar"))
  .sendSync();

Callbacks isolate parameters by location so that names never conflict, and as a result, we can continue using short setter functions. The callback functions also act like anonymous namespaces, so the user doesn't need to import whatever class the generated API uses to set path parameters, query parameters, and so on. It's a small convenience.

v0.1.6

This releases the Fluent Requests milestone in which we establish the request-to-response API. Users can now not only create and parameterize requests, but also send them via the API, receive a response via the API, and even deserialize content bodies all without directly accessing the native HTTP API.

We still only support path and query parameters and do not yet provide helpers for accessing response headers or cookies, but in both cases users are still able to dip into the native HTTP API to get what they need.

v0.1.5

Add support for query parameters in generated code and in the support library.

v0.1.4

Binary data types are now represented using the java.nio.ByteBuffer class instead of boxed-primitive Byte[] arrays, offering a superior API by default. Note that ByteBuffer#array returns the array which backs the buffer, so the user always has a means of obtaining byte[] and Byte[] instances where necessary.

v0.1.3

Add support for operationIDs and parameter names in kebab-case, snake_case, camelCase, and PascalCase.

v0.1.2

This releases updates from the Path Parameters milestone, in which we add manual and fluent API path parameter support for simple-style parameters.