support jakarta messaging

[pjfanning]

Most of the javax libs now have jakarta equivalents. This includes JMS - now there is Jakarta Messaging.

We should clone our jms connector and produce an equivalent that uses https://mvnrepository.com/artifact/jakarta.jms/jakarta.jms-api/3.1.0 instead.

[samueleresca]

I can take a look at this

[samueleresca]

I was taking a look into this. Currently jms depends on 2 test packages that relies on javax.jms libs:

"io.github.sullis" %% "jms-testkit" % "1.0.4" % Test,
"com.github.pjfanning" % "jmswrapper" % "0.1.0" % Test

@pjfanning Do you have any plan to release a jmswrapper using jakarta? Am I ok to open a PR on jmswrapper for supporting jakarta.jms? I can reach out sullis to understand their plan

[pjfanning]

@samueleresca I already have the Jakarta code in a branch.

https://github.com/pjfanning/JmsWrapper/tree/jakarta

I just created a new project but the GitHub tool to import code from other repos is offline tonight.

https://github.com/pjfanning/JakartaMSWrapper

I will look again tomorrow but it shouldn't be hard to release a jakartamswrapper in the near future.

[pjfanning]

I released https://mvnrepository.com/artifact/com.github.pjfanning/jakartamswrapper/0.1.0

[samueleresca]

I have linked the PR containing the new jakartams connector. The connector uses jakarta.jms 3.0.0 instead of jakarta.jms 3.1.0 because the latter does not support Java 8. Therefore, the new connector only supports Jakarta Messaging 3.0, not 3.1

@pjfanning I don't remember what we decided in regards of dropping the Java 8 support? Is there any plan to do that soon? I'm wondering if it is worth to pause the jakarta connector until we drop Java 8 support. It would allow us to support all the versions of Jakarta Messaging and it would make the transition smoother (See the issues highlighted in #674 description)

[pjfanning]

If we merge Jakarta JMS 3.0 support to Pekko Connectors, is it possible that Java 11+ users could just upgrade the Jakarta JMS themselves? Or are there breaking API changes in Jakarta JMS 3.1 that prevent code compiled with Jakarta JMS 3.0 from working at runtime with Jakarta JMS 3.1?

[samueleresca]

There is no breaking changes that prevent the consumer to upgrade and one can decide to upgrade to jakarta.jms-api 3.1.0.

If we are happy with that #674 is ready to review