feat!: remove duplicate schemas

[jonaslagoni]

Description
Even though we enabled the reusability of schemas in #364, the documents were never adapted, leaving a lot of unnecessary documents. This removes those and uses the common definitions.

This means there will no longer be anything called http://asyncapi.com/definitions/x.x.x/avroSchema_v1.json or http://asyncapi.com/definitions/x.x.x/openapiSchema_3_0.json but only http://asyncapi.com/common/avroSchema_v1.json and http://asyncapi.com/common/openapiSchema_3_0.json

Related issue(s)
Should have been fixed as part of #364

[jonaslagoni]

Think we have to move this over to a next release branch

[Pakisan]

Looks valid for me

The base branch was changed.

[jonaslagoni]

@dalelane @lbroudoux because of the Kafka binding change Github need one of you to take a look when you can 🤙

[smoya]

LGTM! 🚀🌔

[smoya]

@jonaslagoni Not a good deal to have the need of serving those common schemas under the path common on the root of http://asyncapi.com. Not only because the need of adding an extra redirection but also because it is requiring a new path /common that is not so intuitive in terms of naming (what is common in relation to the AsyncAPI website?).

WDYT about http://asyncapi.com/schemas/common? This will require a move of the common dir under schemas directory.

[jonaslagoni]

@jonaslagoni Not a good deal to have the need of serving those common schemas under the path common on the root of http://asyncapi.com. Not only because the need of adding an extra redirection but also because it is requiring a new path /common that is not so intuitive in terms of naming (what is common in relation to the AsyncAPI website?).

WDYT about http://asyncapi.com/schemas/common? This will require a move of the common dir under schemas directory.

Schemas hold the bundled versions, and think we should keep it clean like that 🤔

What about under definitions?

[smoya]

What about under definitions?

Fine with it.

[Pakisan]

@jonaslagoni @smoya maybe repeat structure from jasyncapi?

Current tests, which I'm writing now, in other branch, were grouped by next logic

• models/[v2|v3]
• schemas/[openapi|asyncapi|avro|json]
• /schemas/asyncapi/security schemas/[v2|v3]/{security implementation}

They could be unified for all versions, but in v3 version one property was renamed for OAuth2 flow 😣

[jonaslagoni]

@jonaslagoni @smoya maybe repeat structure from jasyncapi?

Current tests, which I'm writing now, in other branch, were grouped by next logic

* models/[v2|v3]

* schemas/[openapi|asyncapi|avro|json]

* /schemas/asyncapi/security schemas/[v2|v3]/{security implementation}

They could be unified for all versions, but in v3 version one property was renamed for OAuth2 flow 😣

@Pakisan mind opening an issue for it? 🙂 It will for sure be lost in this PR 😅

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud

[smoya]

LGTM! 🚀🌔

[asyncapi-bot]

🎉 This PR is included in version 7.0.0-next-major.2 🎉

The release is available on:

• npm package (@next-major dist-tag)
• GitHub release

Your semantic-release bot 📦🚀