Re: [PROPOSAL] Jakarta approach for ActiveMQ 5.x broker

2023-04-05 Thread Robbie Gemmell
I dont really understand what your table of combinations entries say, and so why Option 1 would be to support "3 (or more)" LTS branches but the other only 2, so its hard to reply specifically around that. Adding -javax modules on a new branch thats primary-jakarta just doesnt really make sense to

Re: [PROPOSAL] Jakarta approach for ActiveMQ 5.x broker

2023-04-05 Thread Robbie Gemmell
I had assumed you would use Spring 6 on the Jakarta branch, though still targeting 11 with the client etc, but requiring 17 for build and using those modules with spring 6 requirement (im not clear which bits those are...but sounds like its more widespread than I thought it was). On Wed, 5 Apr 202

Re: [PROPOSAL] Jakarta approach for ActiveMQ 5.x broker

2023-04-05 Thread Matt Pavlovich
I agree w/ Chris. I don’t think there is harm in keeping a -jakarta client module in 5.18.x. It provides runway for users that lag on JDK adoption and are not using Spring 6. A couple of technical notes to keep in mind about JDK-Spring-Jakarta coupling *specific* to ActiveMQ 5: 1. Spring 6 sup

Re: [PROPOSAL] Jakarta approach for ActiveMQ 5.x broker

2023-04-05 Thread Christopher Shannon
All fair points Robbie. I'd still like to leave the jakarta client in 5.18.x just as it gives some compatibility for clients only even if it's going to go away in 5.19.x. So how about the following: 5.18.x - Still javax support with just a jakarta client. This can be a long term LTS, at least for

Re: [PROPOSAL] Jakarta approach for ActiveMQ 5.x broker

2023-04-05 Thread Robbie Gemmell
No extra -javax client module module. People wanting Jakarta client support would use 5.19.x. People wanting javax client support would just use 5.18.x as they would today. I'd even consider removing the extra 5.18.x -jakarta client module personally (could be super nice and add a maven relocation

Re: [PROPOSAL] Jakarta approach for ActiveMQ 5.x broker

2023-04-05 Thread Christopher Shannon
So if 5.19.x just becomes Jakarta API (and not new modules) then I assume we would just have an extra client module for javax? Basically the inverse of 5.18.x (where we primarily use javax and have a jakarta client module) I guess that will be fine but it is pretty unusual to make such a large bre

Re: [PROPOSAL] Jakarta approach for ActiveMQ 5.x broker

2023-04-05 Thread Jean-Baptiste Onofré
Hi Agree, it was basically my proposal in a previous email: I would not use different artifacts, just change to the major version (5.19.x). If people still want to use javax.jms, then he can use 5.18.x (that we can "flag" as LTS). Regards JB On Mon, Apr 3, 2023 at 10:20 PM Christopher Shannon w