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 <christopher.l.shan...@gmail.com> wrote: > > 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 breaking change in the broker but also have a > separate module we still release that supports the old JMS 2.0 spec jar, > like Artemis does. This would require more work but might be an option for > someone who's code hasn't been upgraded to the new API but wants the latest > version. > > On Tue, Jan 10, 2023 at 7:44 AM Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > > > 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 use. > > spring-beans/spring-core doesn't change here. spring-jms, etc yes they > > changed. I did the change on the broker first (as it uses > > spring-aop/spring-beans/spring-core). But that's correct, better to > > postpone to 5.19.x. > > 3. I'm doing a full pass on the tests, also reevaluating the profiles. > > I will share some details. > > > > I will update Jira with the releases plan. > > > > Thanks, > > Regards > > JB > > > > On Tue, Jan 10, 2023 at 12:40 PM Christopher Shannon > > <christopher.l.shan...@gmail.com> wrote: > > > > > > 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 > > > doesn't Spring 6 require Jakarta and JDK 17 (as Robbie pointed out)? So > > if > > > you wanted to include support for that for 5.18.x wouldn't that also > > imply > > > we have to have the Jakarta changes too? Also, I haven't tested with JDK > > 17 > > > but I assume the broker should be compatible with it at runtime (also > > > required for Spring 6). We could also easily add a Jenkins job for JDK 17 > > > if we haven't already. > > > > > > Speaking of which, it looks like the Jenkins build has had a lot of > > > failures and has been unhappy with the Advisory tests since back in > > > November which is odd as it's complaining about JMX (instance already > > > exists). I just re-kicked off a 5.17.x build so will see if it happens > > > again but may need to fix something. Running the tests by itself locally > > > work fine. > > > > > > On Tue, Jan 10, 2023 at 6:28 AM Robbie Gemmell <robbie.gemm...@gmail.com > > > > > > wrote: > > > > > > > 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? > > > > > > > > Doesnt Spring 6 require Java 17, and so anything using it would > > > > similarly? Is the thinking to change the minimum globally, or e.g just > > > > for specific bits using it and then e.g have divergent requirements > > > > for build (17+) and runtime (11+ or 17+ depending on what bits you > > > > use)? > > > > > > > > Matt's reply was around having separate release branches/streams for > > > > java.jms and jakarta.jms namespace support. I think that might be > > > > simplest (and potentially also allowing for different JVM handling > > > > between them) at this stage, I'm doing that elsewhere, though there > > > > are certainly also tradeoffs to it vs alternatives. You were proposing > > > > something different here, can you flesh out your original idea for > > > > comparison? Had you implemented something? > > > > > > > > On Sun, 8 Jan 2023 at 07:19, Jean-Baptiste Onofré <j...@nanthrax.net> > > wrote: > > > > > > > > > > Hi guys, > > > > > > > > > > I started to work on ActiveMQ 5.18.x major release preparation. > > > > > > > > > > Basically, I propose to include (as major changes, in addition of all > > > > > others more "minor" changes :)): > > > > > - JMS 2.x support (mostly client and first part broker) > > > > > - Spring 6 update > > > > > - Jakarta namespace support > > > > > > > > > > I should have the first PRs ready for review very soon. > > > > > > > > > > I would like to propose a first 5.18.0 in Feb. > > > > > > > > > > Thoughts ? > > > > > Regards > > > > > JB > > > > > >
