Skip to content

Releases: aml-org/amf

Changes in 5.0.9

31 May 15:22
aa2d1b3
Compare
Choose a tag to compare

Released May 30, 2022.

JS asset

JVM asset

What's Changed

Full Changelog: 5.0.8...5.0.9

Changes in 5.0.8

04 May 14:42
755b8c5
Compare
Choose a tag to compare

Released May 4, 2022.

JS asset

JVM asset

What's Changed

Full Changelog: 5.0.6...5.0.8

Changes in AMF 5.0.6

01 Apr 13:36
5b7bc93
Compare
Choose a tag to compare

Released Mar 31, 2022.

JS asset

JVM asset

Validation changes:

Fixed invalid validation issues:

  • When declaring a security scheme in a RAML library, using it an API and then converting that API to OAS, the generated OAS was invalid for AMF as the security scheme was not in declarations.
  • When including an URI parameter from resourceTypes in endPoints's path, transformation of model resulted in duplicate parameters.

Behavioral changes:

  • In OAS, a new parsing warning has been added for cases in which API defines a new type with pattern and format. This relates to the fact that not custom formats already define a standard pattern.

What's Changed

Full Changelog: 5.0.5...5.0.6

5.0.5

08 Mar 21:12
5741f90
Compare
Choose a tag to compare

Assets

Released Mar 8, 2022.

JS asset
JVM asset

What's Changed

Full Changelog: 5.0.4...5.0.5

Changes in 5.0.4

08 Feb 15:34
814bdd0
Compare
Choose a tag to compare

Released Feb 8, 2022.

JS asset

JVM asset

New Features

Semantic Extensions

This release contains the official support of "Semantic Extensions". To know more about this feature you can see the docs and the examples

Relevant changes:

Unified path normalization behaviour for JS distribution

The implementation used to normalize paths in AMF was adjusted in JS to align its implementation with JVM. Both now rely on java.net.URI, which has a native implementation provided by scala.js for JS.
This change was relevant for solving APIMF-3517.

AMF Fixed issues

GitHub issues fixed

Changes in 5.0.3

13 Jan 16:46
86a75cd
Compare
Choose a tag to compare

Released Jan 15, 2022.

JS asset

JVM asset

Relevant changes:

Simple inheritance and examples

A simple inheritance is when a type is a child of a parent type, and it defines no properties, or only properties that are documentation related and don't change the behavior or the schema.

These are some examples of simple inheritance in RAML:

BaseTypeString: # base type
    displayName: base type
    description: description of base type
    type: string
    example: "base example"

  # simplest single inheritance
  inline-string: BaseTypeString 

  # similar to inline but more verbose
  simple-inheritance-string:
    type: BaseTypeString 

  # fields like description, displayName, or example don't change the schema, thus this type is still a simple inheritance
  simple-inheritance-with-doc-string: 
    type: BaseTypeString
    description: Description of the simple inheritance type

  # this type defines a `maxLength`, this is not a simple inheritance
  complex-inheritance-string:
    type: BaseTypeString
    description: Description of the complex inheritance type
    maxLength: 3

Previously, the example of the parent type was put into the child type only if it was an inline simple inheritance, now they propagate in any kind of simple inheritance, as we are sure that they will still be valid.

Furthermore, in RAML 0.8 when an example was an invalid reference, the example field and it's metadata was not parsed into the model. Now it's created with an empty example list as it's done in the other specs.

AMF Fixed issues

GitHub issues fixed

Changes in 5.0.2

14 Dec 12:39
c35b590
Compare
Choose a tag to compare

Changes in AMF 5.0.1

23 Nov 20:42
9971ffd
Compare
Choose a tag to compare

Released Nov 23, 2021.

JS asset

JVM asset

Interface changes:

A new render option has been added to RenderOptions class with the method withSourceInformation that lets you acquire the URI location from where it was originally parsed of any element in the base unit. This only affects the rendering in JSON-LD, and has been added in the issue APIMF-3319.

GitHub fixed issues

  • #1084: Unable to track JSON schema (the raw value) from a payload

AMF Fixed issues

Changes in AMF 5.0.0

18 Oct 20:49
5fb016b
Compare
Choose a tag to compare

Released Oct 14, 2021.

JS asset

JVM asset

Summary

This new mayor version includes changes focused in the client interfaces and internal structure of AMF with the intention of providing a simplified and clean usage. These changes DO NOT modify underlying functionality with regards to the previous version 4.7.8.

Complementary to these release notes, make sure to see our updated documentation with its migration guide, as well as our examples repository.

Interface Changes

Unify all configuration in a single instance removing static behaviour

Why? In AMF 4 functionality was partially pluggable through a static registry. That is why clients had to invoke asynchronous AMF.init() or similar initialization methods in order for AMFs functionality to work correctly. This initialization was not transparent to the end user, and lead to issues which were difficult to reproduce and debug.

This behaviour has been completely removed in favor of immutable configuration instances. These instances are the single point through which a user defines the functionality is wishes to use (support for a certain API Spec as an example), and other parameters such as parsing/render options, or resource loaders. Users can now create multiple AMF configurations and have a clear sense of the capabilities each one has.
More details here.

Functionality is exposed through clients

Why? In AMF 4 functionality was exposed through a variety of classes, and configurable parameters had to be passed on each invocation.

All of our functionality has now been unified into 2 client interfaces. These client classes are obtained directly from a configuration instance, meaning that all of their configurable parameters are used for the operations invoked by the client. This has also allowed us to move functionality that was exposed through methods defined in model classes making their interface more simple.
More details here.

Explicit result feedback for each operation

Why? In AMF 4 operations such as parsing and resolution did not return any validation results, only returning the resulting BaseUnit. If validation results where to occur, these where collected statically and returned when the validation operation was called. This lead to a static collection that stored all validations and could cause potential memory problems in long executions. This also did not give transparency to users that where only interested in parsing or resolution.

Each operation now returns a specific instance of AMFResult, which not only contains the result BaseUnit, but also a list of all the validation result that where collected.

New Functionality

New specification agnostic parsing functionality through composite configurations

Composite configurations such as APIConfiguration.API() which contain capabilities for more that one specification can only be used for parsing. We have maintained this functionality as it offers AMF users the possibility of parsing any content without knowing the specification type beforehand. Any other operation that is invoked when using composite configuration will result in errors, such as rendering, transformation, or validation as they must apply for a particular specification.

New interfaces for scala adopters

In AMF 4 client interfaces where only available for javascript and java, without support for native scala types such as Future or Option. This has now been included giving classes for clients in java, scala, and javascript. More details as to how our package structure is handled can be found in Transparent packet structure heading.

New EventListeners which replace static ExecutionLog

A new AMFEventListener interface has been defined which can be plugged into any configuration. This listener provides additional insights over the execution of AMF through a set of events. Each event has a name, and a set of additional values according to each type.

New id adoption functionality available for BaseUnit

A new functionality was implemented allowing the possibility of adopting the ids of all the elements of a BaseUnit given a certain base uri. This is used internally by AMF after parsing a BaseUnit to make sure all ids are correctly defined. This functionality has been exposed to the end user if there is a need to modify ids from a parsed or created model in a deterministic manner.
An example of this use case can be found here.

Additional Changes

Restructured modules and artifacts

AMF 5 artifacts are now domain scoped. What used to be the amf-client module in AMF 4 is now broken into multiple
modules. The new AMF ecosystem modules are the following:
amf modules

  • amf-cli: CLI client classes
  • amf-api-contract: API domain classes
  • amf-shapes: Schema domain classes
  • amf-aml: AML domain classes
  • amf-validation: Validation domain classes
  • amf-core: Core domain classes
  • amf-rdf: External RDF interface classes

Transparent package structure

AMF 5 is organized in packages according to their visibility and target platform. These are:

  • amf.[module].internal: internal unsafe interface
  • amf.[module].client: client exposed interfaces
    • amf.[module].client.platform: platform (JVM & JS) interface classes
    • amf.[module].client.scala: native scala interface classes

Removed jena-shacl dependency and extracted RDF related functionality in separate artifact

AMF 5 now provides native SHACL validation without the need for jena-shacl. Jena is no longer a standard dependency in
AMF. The new amf-rdf artifact contains the Jena dependency as well as the necessary classes to interface the AMF
model with external RDF models like the Jena. amf-rdf must be explicitly imported. JAR size decreased around 40%

Discontinued support of custom validation functionality

AMF 5 no longer includes functionality for custom validation. We are working on a new separate project solely focused on this regard allowing us to incorporate more features and enhanced performance.

Changes in 4.7.8

28 Sep 17:47
9f05bc9
Compare
Choose a tag to compare

Released Sep 24, 2021.

JS asset

JVM asset

Validation fixes

Array inheritance in RAML

There was a problem resolving some cases of inheritance on array types that generated a validation error of type Incompatible types [array, array].

Example:

types:
  BaseObject:
    type: object
    properties:
      items:
        type: array
        items:
          type: any
  
  ArrayOfObjects:
    type: object[]

  CustomObjectList:
    type: BaseObject
    properties:
      items:
        type: array
        items:
          type: ArrayOfObjects

Examples with disjoint UnionShapes

There was an error in the propagation of examples in disjoint UnionShapes that ended in validation errors of the type expected type: X, found: Y

Example:

{
  "$schema": "http://json-schema.org/draft-07/schema",
  "type": "object",
  "properties": {
    "gender": {
      "type": [
        "string",
        "null"
      ],
      "examples": [
        "M",
        "F",
        "N",
        null
      ]
    }
  }
}

GitHub fixed issues

AMF Fixed issues