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 main (2.x) branch that is used to have rewrite the build into the jakarta variant intended to become 3.x...so the build updates everything to the jakarta version, and that output can then pushed to another branch for release etc.
On Tue, 10 Jan 2023 at 13:17, Robbie Gemmell <[email protected]> wrote: > > 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 approach when Artemis added Jakarta > Messaging support going on a couple of years ago, but at this point > I'd probably go with the full switch and have 2 separate branches. > Thats what I have done elsewhere, and what other projects switching > now seem to be doing. Less build complexity, better/simpler for > testing, uses the same old module names, etc... > > ...however, also means doing more releases (seems like it would happen > anyway in this case), and needs backporting if wanting to support > both, which seems inevitable for quite some time in this particular > case. That said, for 5.x it also seems pretty much every change > released is already backported from main to a branch today, so that > other 'downside' also isnt actually much different than exactly what > is already being done now (besides maybe the occasional import fixup). > > Robbie > > On Tue, 10 Jan 2023 at 12:54, Christopher Shannon > <[email protected]> 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é <[email protected]> > > 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 > > > <[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 > > > > > > > >
