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 <[email protected]> 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 <[email protected]> > 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é <[email protected]> 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 > >
