- Support for JsonInclude.Include.NON_EMPTY and JsonInclude.Include.NON_NULL on relationships.
- The build of crnk has been modified to make use of jdk-bootstrap to ship with a JDK 8 and avoid compaitiblity issues with custom installations.
InMemoryResourceRepositorycan be used standalone without being registered with CrnkBoot. Useful for experimenting and testing.
- The Crnk engine adds support for HTTP methods not specified by JSON:API like PUT and OPTIONS. This allows for custom extensions that make use of those methods.
CrnkExceptionholds the request url on the client-side.
- A self link is added on the top-level to all response documents.
- Support for java.util.Optional based on built-in Jackson support. For more information how to setup Jackson, see https://www.baeldung.com/jackson-optional.
- Refinements to the (still experimental) OpenAPI generator.
UrlBuilderis available from CrnkBoot and, in case of Spring, as bean for injection. It allows the easy construction (and manipulation) of URLs.
- The JPA module has updated its sorting behavior to according to https://stackoverflow.com/questions/8139437/how-to-set-the-column-order-of-a-composite-primary-key-using-jpa-hibernate where Hibernate does sort columns alphabetically rather than by file/line order. Most notable use case are entities with multiple attributes as primary key with paging and no or non-unique sort order. Then crnk already automatically adds the primary key to make sure the order is total. This change ensures to hit the index as generated by Hibernate. But the behavior can also be disabled. More details here.
- BinTray batches have been added to our GitHub page to quick access to current versions.
CrnkCoreAutoConfiguration has been refined to make it more robust against cyclic dependencies between repositories,
CrnkBootand other components. This avoids some situations where Spring either fails or partially loads the application.
The Typescript generation has been simplified to not have a dependency to the (deprecated) Crnk NPM library. This has already be in place for
our plain JSON format. Now the same approach is taken for the regular JSON:API format. A dependency to
ngrx-json-apistill remains that in the future may also become optional.