feat: first draft of JMS Binding Objects

[adamretter]

Resolves asyncapi/spec#919

This is a first draft of a set of JMS Binding Objects. There is a lot of variance between JMS Providers in terms of features and capabilities, however these bindings should work with all providers as they stay within the JMS API.
More features could of course be added in future if desirable!

[github-actions]

Welcome to AsyncAPI. Thanks a lot for creating your first pull request. Please check out our contributors guide useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[rwalpole]

It would be great to see this PR merged. We are using AsyncAPI together with JMS in a major project right now.

[derberg]

Thanks a lot! Left just 2 comments for now

[derberg]

@rwalpole good to hear, whould you mind joining the review of proposed initial jms binding spec?

[KhudaDad414]

Left a few comments.

[adamretter]

@derberg @KhudaDad414 @rwalpole I hope I have addressed all of the review comments that you had. Thanks for the feedback :-) I think it is now ready for a second round of review...

[derberg]

LGTM but from the perspective of bindings repo maintainer, not jms expert. I know zero about the subject

@KhudaDad414 please have another look on JSON Schemas

@rwalpole anything else from your side

@MichaelDavisSolace I think you use JMS at Solace afaik...at least I think you asked about JMS binding one time. Would you have time to look at this PR?

@rcarrascosps you created #87 so maybe you want to join review?

@fmvilas anything from your side?

---

@adamretter Let's give these folks a week for reply. In the meantime can you clarify if you can become a maintainer of this specific binding? just like we have others in https://github.com/asyncapi/bindings/blob/master/CODEOWNERS

[KhudaDad414]

Schemas seems to follow the documentation. 👍

[adamretter]

In the meantime can you clarify if you can become a maintainer of this specific binding?

@derberg This work was done on behalf of one of my clients; so I can maintain it only for as long as they are asking me to do so.

[rcoppen]

I think this helps clarify that the server binding could be from a JMS Provider and that the resulting AsyncAPI doc might include more than one binding. Moving forward it might be useful to solve the JMS Provider flag in a more generic way by adding that into the provider binding or protocol binding (in the case of something like AMQP).

[adamretter]

Let's give these folks a week for reply

@derberg It's now been two weeks and I have also addressed some suggestions from @rcoppen.
Do you think this might now be ready to merge please?

[adamretter]

Any updates on this please?

[adamretter]

@derberg any updates on this please?

[derberg]

@adamretter sorry, was out on holidays. I see that @rcoppen have a 👍🏼 and @SrfHead is ready to be codeowner here, so please go ahead and update in the PR the CODEOWNERS file to add them as owners of JMS binding.

[adamretter]

@derberg Thanks. I hope you had a nice holiday? I have now committed the CODEOWNERS as you requested!

[derberg]

@KhudaDad414 please approve again. No changes to the binding, @adamretter was just adding CODEOWNERS

[derberg]

@jonaslagoni we are letting in a new binding. Anything we should remember to do because of coming 3.0?

get schemas in spec-json-schemas repo, and what else?

[jonaslagoni]

@jonaslagoni we are letting in a new binding. Anything we should remember to do because of coming 3.0?

get schemas in spec-json-schemas repo, and what else?

Nothing tbh, you just have the same question as I gave the other codeowners @adamretter @rcoppen @SrfHead: #182 (comment)

You can find a lot of information about the changes here: #182 (comment)

Also happy to help out, and feel free to join our spec 3.0 meetings if you have questions you want answered live 🙂

[derberg]

/rtm

[derberg]

@adamretter @rcoppen @SrfHead as per @jonaslagoni comment. In short, this binding that was just merged is for AsyncAPI 2.x and you need to make sure it will still be working fine with 3.x. So look on linked materials and any changes need to be done against next-major-spec branch.

also, in 3.0 we remove json schemas from this repo, to have them better integrated with current tooling, we move them to https://github.com/asyncapi/spec-json-schemas. So please open up a followup PR to get your bindings in https://github.com/asyncapi/spec-json-schemas/tree/next-major-spec/bindings + make sure they are referenced in respective *BindingsObject.json files in https://github.com/asyncapi/spec-json-schemas/tree/next-major-spec/definitions/3.0.0