Fix #47. Sort paths and components for deterministic specification

[hiddewie]

Problem

There is non-deterministic output of the generation of the OpenAPI 3.0 document produced by this plugin. Also see #47.

When the file is committed to a source code repository, this causes a diff without changing the actual content of the specification.

The sorting is done by a specialized class, which may be removed after this has been fixed in swagger-core.

This PR

• Add sorting of:
  • paths
  • components:
  • Schemas (recursively)
  • Responses
  • Parameters
  • Examples
  • RequestBodies
  • Headers
  • SecuritySchemes
  • Links
  • Callbacks
  • Extensions
• Improve tests by adding strict file contents equality for existing fixtures. Some of the fixtures in the source code were actually not waht the plugin generated (the OpenAPI content was equal, but the file contents were not).

This should solve the problem.

References to other issues and pull requests in Swagger Core:

• https://github.com/swagger-api/swagger-core/issues/3475
• https://github.com/swagger-api/swagger-core/pull/3476
• swagger-api/swagger-core#2775
• swagger-api/swagger-core#2828
• swagger-api/swagger-core#3266
• swagger-api/swagger-core#2400

[langecode]

Great, thx. I will take a look today or tonight and possibly make a new release including this feature.

[hiddewie]

We found another non-deterministic issue with the order of the properties of a Schema (/components/schemas/*/properties). We will also push a fix for that as well on this branch.

All the sorting logic will be extracted to a separate class for better separation of concerns.

[hiddewie]

I also created https://github.com/swagger-api/swagger-core/pull/3613 which solves exactly this problem in Swagger Core, without the code in this PR.

[hiddewie]

Thank you @langecode for the very quick response!

[langecode]

You're welcome. I did change the implementation a little bit but should have the same sematics :)