This became a problem when ActiveMQ 5.18 went from dependency groupId 'javax.jms' to 'jakarta.jms'.
The Jakarta JMS API 2 still uses javax.jms package name, but has groupId jakarta.jms.
This lead to problems where "auto-upgrade" in dependency resolution didn't work anymore, so instead we got both APIs - and since the v2 API is a superset of 1.1, we could get problems if the 1.1 was earlier on the classpath.
Instead, rely on the user "bringing their own" JMS API. Mats3 thus actually only rely on features from v1.1, but can run on v2. Mats3 expects the JMS API dependency to be brought in by the user including a JMS ConnectionFactory API implementation.
This became a problem when ActiveMQ 5.18 went from dependency groupId 'javax.jms' to 'jakarta.jms'. The Jakarta JMS API 2 still uses javax.jms package name, but has groupId jakarta.jms. This lead to problems where "auto-upgrade" in dependency resolution didn't work anymore, so instead we got both APIs - and since the v2 API is a superset of 1.1, we could get problems if the 1.1 was earlier on the classpath.
Instead, rely on the user "bringing their own" JMS API. Mats3 thus actually only rely on features from v1.1, but can run on v2. Mats3 expects the JMS API dependency to be brought in by the user including a JMS ConnectionFactory API implementation.