[HEADS-UP] Release ActiveMQ Artemis soon...

2023-01-10 Thread Clebert Suconic
I usually give a time frame that I'm never able to follow. Time time, let's just say we are releasing it as soon as possible and ready... if you could use this thread for anything that needs to be waited before release, please send a link to a PR discussion or JIRA here. Thanks... Clebert

Re: Starting ActiveMQ 5.18.x preparation/update

2023-01-10 Thread Robbie Gemmell
I should add that one other approach I've seen which is somewhat combining the approaches is at Quarkus, where they are currently (not sure if this is intended going forward, after the 3.0 stuff actually gets released, but is how its being developed for now) using rewrite tooling thats part of the

Re: Starting ActiveMQ 5.18.x preparation/update

2023-01-10 Thread Robbie Gemmell
Artemis currently does the dual-modules thing, with the 'main' artifacts are the same JMS 2 based ones that were always there from the start, but with additional modules added that take the existing source and create new 'jakarta variants', e.g artemis-jakarta-client. I think that was a sensible

Re: Starting ActiveMQ 5.18.x preparation/update

2023-01-10 Thread Jean-Baptiste Onofré
Hi Chris, yes, makes sense. I agree with you: even it's more work, I think from user community standpoint, it's better to have two different artifacts/modules. I will create/update Jira to mention this. Thanks, Regards JB On Tue, Jan 10, 2023 at 1:53 PM Christopher Shannon wrote: > > If we

Re: Starting ActiveMQ 5.18.x preparation/update

2023-01-10 Thread Christopher Shannon
If we do have a breaking change and drop JMS jar entirely in 5.19.x then I think we will need to support 5.18.x for a while. Even though old JMS clients would work with 5.19.x (just not in the same JVM) it would be good to support JMS jar still for a while longer. The other option is we do the

Re: Starting ActiveMQ 5.18.x preparation/update

2023-01-10 Thread Jean-Baptiste Onofré
Hi, Those are valid points: 1. For Jakarta, I plan to change the dep and rename on dedicated branch (5.19.x). The intention is to introduce breaking change here (as spring or camel did). 2. Spring 6: you are right for JDK 17 (I forgot this part). Jakarta namespace depends of the spring module in

Re: Starting ActiveMQ 5.18.x preparation/update

2023-01-10 Thread Christopher Shannon
JB, I was writing up a response when I saw Robbies and I have the same questions. What is your plan for handling the Jakarta namespace? Are you just using Maven to generate another module that's a copy of activemq-client? Also, you said Spring 6 is not very difficult and could be in 5.18.x but

Re: Starting ActiveMQ 5.18.x preparation/update

2023-01-10 Thread Robbie Gemmell
Would the plan be to have these first 5.18 releases marked as e.g. alphas to set people's expectations appropriately around it not yet implementing most of JMS 2's new functionality, only some of the new 'simplified' API? Or are the PRs going to pick up on completing [more of] the impl first?