Yup. I propose to update the website with a table with different versions (as we do in Karaf).
Regards JB On Wed, Apr 12, 2023 at 4:08 PM Christopher Shannon <christopher.l.shan...@gmail.com> wrote: > > Yep, this seems like a good plan to me. If people want to upgrade to > Jakarta we will have to require Spring 6 (due to the configuration) which > requires JDK 17 and I think requiring JDK 17 is reasonable for that version > as JDK 21 is almost out. > > I also want to add that we should upgrade 5.18.x to Jetty 10.x and 5.19.x > can be Jetty 11/12 > > On Wed, Apr 12, 2023 at 9:58 AM Matt Pavlovich <mattr...@gmail.com> wrote: > > > Hi Robbie- > > > > Yep, I’m back to agreeing with planning to move forward with the two > > separate versions is the way to go. Chris Shannon has the jetty > > continuation thing resolved, so that was the only potential snag for back > > porting. > > > > Proposed plan for 5.19.x and to LTS-ify 5.18.x: > > > > 5.18.x LTS - JDK 11 + javax broker + Spring 5 + activemq-client-jakarta > > 5.19.x - JDK 17 + jakarta broker + Spring 6 > > > > Thanks, > > Matt Pavlovich > > > > > On Apr 5, 2023, at 12:34 PM, Robbie Gemmell <robbie.gemm...@gmail.com> > > wrote: > > > > > > 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 me if still supporting an older version > > > that is actually primary-javax. There may be something obvious I'm > > > missing, but it seems more likely the people who are not updating APIs > > > also wont typically want to change all their dependencies in order to > > > not-update their usage. Theyll just use the older still-supported > > > primary-javax version. Same way they often use absolutely ancient > > > versions now already. > > > > > > Adding -javax modules to a primary-jakarta version might make sense to > > > me as a final fallback when otherwise dropping support for all > > > primary-javax versions, when at that point either the user would have > > > to either update the API they use or have to rework their dependencies > > > in order to not update the API. Personally I think it would be simpler > > > just supporting an existing primary-javax version (or even make a > > > newer one), or to decide you have actually finally dropped javax > > > support. > > > > > > It would seem easy enough to continue targeting JDK 11 on a new branch > > > with the client at least, even if needing 17 for the broker, if > > > wanting to support Jakarta client-only users on JDK11 but taking the > > > rest up to 17 to bring in Spring 6 ? > > > > > > On Wed, 5 Apr 2023 at 15:57, Matt Pavlovich <mattr...@gmail.com> wrote: > > >> > > >> 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 support is needed to address user demand for Spring Boot > > Starter > > >> 2. The *-web modules _require_ JDK 17 due to spring-web dependency > > >> 3. *-web modules drag a JDK 17 runtime requirement for the Apache > > runtime distribution > > >> 4. All the other modules can be compiled JDK 11 for users with custom > > assemblies > > >> > > >> > > >> Based on my previous repackaging and the inflight Jakarta PR work, I > > think back porting patches b/w Jakarta and non-Jakarta isn’t going to > > require too much heavy lifting. > > >> > > >> a. javax vs jakarta change is isolated to import lines, which should > > rarely be in the patch diffs > > >> b. *-web modules don’t change frequently > > >> c. jetty-continuation (discontinued) to jakarta.servlet async is the > > biggest _coding_ change required, and we could do that in a javax-based LTS > > tree as well > > >> > > >> > > >> Based on the above: > > >> > > >> i. I don’t see a huge win with for Jakarta broker without Spring 6 > > (since we require spring-web) we’d have jakarta for some modules and javax > > for Servlet > > >> Ii. Providing *-javax modules would be a way to simplify managing a > > Spring 6 + JDK 17 + javax build without a separate branch and set of > > releases > > >> > > >> A table of potential combinations: > > >> > > >> 5.18.x - Spring 5 + JDK 11 + javax (client and broker) > > >> 5.18.x (-jakarta client) - Spring 5 + JDK 11 + jakarta (client-only) > > >> 5.19.x - Spring 6 + JDK 17 + jakarta (client and broker) > > >> 5.19.x (-javax modules) - Spring 6 + JDK 17 + javax (client and broker) > > >> > > >> > > >> Based on all the above, I think the discussion could be reduced to a > > couple practical options: > > >> > > >> Option 1: Gap versions and support 3 (or more) LTS branches and do not > > do -javax modules in 5.19.x > > >> > > >> Option 2: Add -javax modules to 5.19.x and support 2 LTS branches > > >> > > >> Thanks, > > >> Matt Pavlovich > > >> > > >>> On Apr 5, 2023, at 9:20 AM, Christopher Shannon < > > christopher.l.shan...@gmail.com> wrote: > > >>> > > >>> 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 bug fixes. We will probably want to backport > > some > > >>> features too for a while. > > >>> 5.19.x - Becomes Jakarta API only. Still support JDK 11 and by default > > >>> would still have Spring 5.3.x but will be of course compatible with > > Spring > > >>> 6 and Spring boot 3, etc. > > >>> 5.20.x - By this release JDK 21 LTS should be out so I say we bump to > > >>> require JDK 17 (we can bump other things like Jetty/Spring 6 at the > > same > > >>> time) > > >>> > > >>> We could also bump to JDK 17 for 5.19.x if it's too much of a pain to > > >>> support JDK 11 but I think it should be doable. > > >>> > > >>> In terms of which features are actually supported/implemented for the > > new > > >>> APIs is another discussion. Obviously each release would add more. I > > >>> haven't had time yet to look more into shared subscriptions but likely > > we'd > > >>> leverage the existing composite destination/virtual topics that exist > > in > > >>> the broker to support it but I'm not sure if it would be client/broker > > side > > >>> etc. > > >>> > > >>> Thoughts? > > >>> > > >>> On Wed, Apr 5, 2023 at 8:59 AM Robbie Gemmell < > > robbie.gemm...@gmail.com> > > >>> wrote: > > >>> > > >>>> 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 for it to the initial 5.19.0 release to > > >>>> point them back to the normal client module, though as its not in > > >>>> widespread use and doesnt even work yet, a need for that is unclear). > > >>>> > > >>>> I dont particularly care what version it is called. However I will say > > >>>> I dont think it would particularly be any more unusual to call it > > >>>> 5.19.x vs 5.18.x than it was with many other more impactful changes > > >>>> that have been made in 5.n -> 5.n+1 releases in the past ~15 years. > > >>>> While awkward in some ways, its actually probably a more trivial > > >>>> change in the end compared to many prior changes in that time. Folks > > >>>> that want to update their stuff to the new API make a trivial version > > >>>> number update. Folks that dont, will not. Actual implementation > > >>>> behaviours would remain the same, unlike with many 5.x bumps. Could > > >>>> jump it to 5.30.x to separate and align with supporting Jakarta > > >>>> Messaging 3 ;) > > >>>> > > >>>> On Wed, 5 Apr 2023 at 12:31, Christopher Shannon > > >>>> <christopher.l.shan...@gmail.com> wrote: > > >>>>> > > >>>>> 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 > > >>>>> breaking API change without bumping major versions. I would argue > > that > > >>>>> should really be a 6.0 release but everyone knows how that > > conversation > > >>>>> would go with versioning so I guess we are stuck on 5.19.x > > >>>>> > > >>>>> On Wed, Apr 5, 2023 at 5:17 AM Jean-Baptiste Onofré <j...@nanthrax.net > > > > > >>>> wrote: > > >>>>> > > >>>>>> 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 > > >>>>>> <christopher.l.shan...@gmail.com> wrote: > > >>>>>>> > > >>>>>>> Based on what Robbie is saying we wouldn't have any new modules at > > >>>> all. I > > >>>>>>> would just be different versions, one version is javax and one is > > >>>> jakarta > > >>>>>>> which is what Qpid JMS did. (Jakarta is 2.x and javax is 1.x) > > >>>>>>> > > >>>>>>> On Mon, Apr 3, 2023 at 1:32 PM Matt Pavlovich <mattr...@gmail.com> > > >>>>>> wrote: > > >>>>>>> > > >>>>>>>> Yeah, I agree w/ Robbie. I think this makes the most sense > > >>>> considering > > >>>>>>>> Jakarta namespace will be default going forward for all new apps. > > >>>>>>>> > > >>>>>>>> When migrating existing apps, it’ll most likely be all javax deps > > >>>> to > > >>>>>>>> jakarta, so that makes for a nice clean version-number-only > > change. > > >>>>>>>> > > >>>>>>>> For example, 'spring-web’ v6 w/ Jakarta artifactId is still just > > >>>>>>>> ’spring-web’. > > >>>>>>>> > > >>>>>>>> Thanks, > > >>>>>>>> Matt Pavlovich > > >>>>>>>> > > >>>>>>>>> On Apr 3, 2023, at 11:53 AM, Robbie Gemmell < > > >>>>>> robbie.gemm...@gmail.com> > > >>>>>>>> wrote: > > >>>>>>>>> > > >>>>>>>>> Though that was over 2 years ago, and at the time having the > > >>>> separate > > >>>>>>>>> -jakarta modules was probably the most obvious way to go given > > >>>> very > > >>>>>>>>> few were likely going to actually use those new modules at the > > >>>> time, > > >>>>>>>>> with the prior/existing stuff clearly still being the focus for > > >>>>>> almost > > >>>>>>>>> everyone, and thus making it harder to justify alternatives like > > >>>> e.g > > >>>>>>>>> maintaining separate branches for both spec impls back then. Now, > > >>>>>>>>> usage will probably be a fair bit more bifurcated from newer > > >>>>>> framework > > >>>>>>>>> versions having updated to the new specs and various users either > > >>>>>>>>> updating to use them or else just using them for any new dev > > >>>> stuff, > > >>>>>>>>> but still many users that dont update their stuff. > > >>>>>>>>> > > >>>>>>>>> More recently, I'd say most projects I see making similar > > >>>> transitions > > >>>>>>>>> are using their existing modules for the new specs just with a > > >>>> new > > >>>>>>>>> version, and if they want to support the old specs then doing so > > >>>> by > > >>>>>>>>> maintaining a previous version stream, having each stream be > > >>>> targeted > > >>>>>>>>> to one spec and 'fully tested'. That is what I chose to do for > > >>>>>>>>> qpid-jms last year, and what I would currently choose if deciding > > >>>>>>>>> again just now. > > >>>>>>>>> > > >>>>>>>>> On Mon, 3 Apr 2023 at 15:04, Justin Bertram <jbert...@apache.org > > >>>>> > > >>>>>> wrote: > > >>>>>>>>>> > > >>>>>>>>>> For what it's worth Artemis created new coordinates for the > > >>>> Jakarta > > >>>>>>>> modules > > >>>>>>>>>> and left the existing ones the same. Folks who are migrating are > > >>>>>>>> actually > > >>>>>>>>>> touching their applications in most (if not all) circumstances. > > >>>> It > > >>>>>> makes > > >>>>>>>>>> sense to require them to change the GAV. > > >>>>>>>>>> > > >>>>>>>>>> In my opinion folks who just want to upgrade their existing > > >>>> (i.e. > > >>>>>> javax) > > >>>>>>>>>> systems shouldn't have to change anything but the version > > >>>> number. > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> Justin > > >>>>>>>>>> > > >>>>>>>>>> On Mon, Apr 3, 2023 at 6:20 AM Christopher Shannon < > > >>>>>>>>>> christopher.l.shan...@gmail.com> wrote: > > >>>>>>>>>> > > >>>>>>>>>>> Matt, > > >>>>>>>>>>> > > >>>>>>>>>>> My main concern with that is with new -javax modules everyone > > >>>> has > > >>>>>> to > > >>>>>>>> change > > >>>>>>>>>>> to new GAV and then they have to change GAV again if we drop > > >>>> the > > >>>>>> javax. > > >>>>>>>>>>> > > >>>>>>>>>>> But this might just be the way it is and users will have to > > >>>> make > > >>>>>>>> changes to > > >>>>>>>>>>> their build that is more than just a version change. > > >>>>>>>>>>> > > >>>>>>>>>>> On Fri, Mar 31, 2023 at 2:17 PM Matt Pavlovich < > > >>>> mattr...@gmail.com > > >>>>>>> > > >>>>>>>> wrote: > > >>>>>>>>>>> > > >>>>>>>>>>>> Hi Christopher- > > >>>>>>>>>>>> > > >>>>>>>>>>>> After taking yesterday to get most of the way through the > > >>>> jakarta > > >>>>>>>>>>>> conversion, I think we can go without the version gap. > > >>>>>>>>>>>> > > >>>>>>>>>>>> I think option #1 gives us the best approach. After a period > > >>>> of > > >>>>>> time > > >>>>>>>> we > > >>>>>>>>>>>> can just ‘drop’ the javax modules and not have to cause users > > >>>> to > > >>>>>>>> change > > >>>>>>>>>>>> anything else back to have clean GAV coordinates. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Thanks, > > >>>>>>>>>>>> Matt Pavlovich > > >>>>>>>>>>>> > > >>>>>>>>>>>>> On Mar 30, 2023, at 3:49 PM, Christopher Shannon < > > >>>>>>>>>>>> christopher.l.shan...@gmail.com> wrote: > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> Thanks Matt for bringing this up. We definitely need to > > >>>> figure > > >>>>>> out a > > >>>>>>>>>>> path > > >>>>>>>>>>>>> forward as there is a lot of confusion about this still and > > >>>>>> users are > > >>>>>>>>>>>>> getting bit by it when trying to upgrade to Spring 6 and > > >>>> Spring > > >>>>>> boot > > >>>>>>>> 3. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> Ultimately I think we will need to support both javax and > > >>>>>> jakarta for > > >>>>>>>>>>>> quite > > >>>>>>>>>>>>> a while because while some users are going to want to use > > >>>> newer > > >>>>>>>>>>>>> technologies that require jakarta (like Spring 6 ) others > > >>>> will be > > >>>>>>>> happy > > >>>>>>>>>>>> to > > >>>>>>>>>>>>> stay on the old APIs for a while. So the question becomes > > >>>> what > > >>>>>> is the > > >>>>>>>>>>>> best > > >>>>>>>>>>>>> way to do that. I do think that some sort of repackaging is > > >>>>>> probably > > >>>>>>>>>>> the > > >>>>>>>>>>>>> way to go like we did for the client but to do it for all the > > >>>>>>>> relevant > > >>>>>>>>>>>>> modules and release both. We can keep 5.18.x as a long > > >>>> running > > >>>>>>>> branch > > >>>>>>>>>>> to > > >>>>>>>>>>>>> back port but it would still be nice if the latest worked for > > >>>>>> either > > >>>>>>>>>>> API > > >>>>>>>>>>>>> (ie 5.19.x). I'm thinking more about it and we can probably > > >>>> just > > >>>>>> do > > >>>>>>>> it > > >>>>>>>>>>> in > > >>>>>>>>>>>>> 5.19.x and don't need a gap version. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> I can see 3 ways to release both: > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> *1) Create duplicate modules (like we did with the client > > >>>> for > > >>>>>>>> jakarta > > >>>>>>>>>>> in > > >>>>>>>>>>>>> 5.18.x). *This works but means a lot of extra modules to > > >>>>>> maintain but > > >>>>>>>>>>> is > > >>>>>>>>>>>>> probably the most flexible as you can do custom things in > > >>>> each > > >>>>>> module > > >>>>>>>>>>>>> easily. We could create BOM files for people to use to > > >>>> import the > > >>>>>>>> right > > >>>>>>>>>>>>> things to keep things consistent. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> <dependency> > > >>>>>>>>>>>>> <groupId>org.apache.activemq</groupId> > > >>>>>>>>>>>>> <artifactId>activemq-broker-javax</artifactId> > > >>>>>>>>>>>>> <version>5.19.0</version> > > >>>>>>>>>>>>> </dependency> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> <dependency> > > >>>>>>>>>>>>> <groupId>org.apache.activemq</groupId> > > >>>>>>>>>>>>> <artifactId>activemq-broker-jakarta</artifactId> > > >>>>>>>>>>>>> <version>5.19.0</version> > > >>>>>>>>>>>>> </dependency> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> *2) Don't add new modules, just keep the same ones but have > > >>>> each > > >>>>>>>> module > > >>>>>>>>>>>>> build 2 jars using classifiers. *We could just have each > > >>>> module > > >>>>>>>> build 2 > > >>>>>>>>>>>>> jars and repackage. My primary concern about sharing the > > >>>> same > > >>>>>> module > > >>>>>>>>>>> for > > >>>>>>>>>>>>> both APIs would be if the Jakarta API becomes different > > >>>> enough > > >>>>>> that > > >>>>>>>>>>>>> repackaging doesn't work due to changes between it and javax > > >>>> but > > >>>>>> we > > >>>>>>>>>>> might > > >>>>>>>>>>>>> still be able to make this work by having each classified jar > > >>>>>> only > > >>>>>>>> pull > > >>>>>>>>>>>> in > > >>>>>>>>>>>>> certain things. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> <dependency> > > >>>>>>>>>>>>> <groupId>org.apache.activemq</groupId> > > >>>>>>>>>>>>> <artifactId>activemq-broker</artifactId> > > >>>>>>>>>>>>> <version>5.19.0</version> > > >>>>>>>>>>>>> <classifier>javax</classifier> > > >>>>>>>>>>>>> </dependency> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> <dependency> > > >>>>>>>>>>>>> <groupId>org.apache.activemq</groupId> > > >>>>>>>>>>>>> <artifactId>activemq-broker</artifactId> > > >>>>>>>>>>>>> <version>5.19.0</version> > > >>>>>>>>>>>>> <classifier>jakarta</classifier> > > >>>>>>>>>>>>> </dependency> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> *3) Just build with a different version (this is what Guava > > >>>> does > > >>>>>> with > > >>>>>>>>>>> jre > > >>>>>>>>>>>>> and android). *This is probably the most annoying as you > > >>>> would > > >>>>>> need > > >>>>>>>> to > > >>>>>>>>>>>>> re-package and then I guess use a different version when > > >>>>>> building. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> <dependency> > > >>>>>>>>>>>>> <groupId>org.apache.activemq</groupId> > > >>>>>>>>>>>>> <artifactId>activemq-broker</artifactId> > > >>>>>>>>>>>>> <version>5.19.0-javax</version> > > >>>>>>>>>>>>> </dependency> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> <dependency> > > >>>>>>>>>>>>> <groupId>org.apache.activemq</groupId> > > >>>>>>>>>>>>> <artifactId>activemq-broker</artifactId> > > >>>>>>>>>>>>> <version>5.19.0-jakarta</version> > > >>>>>>>>>>>>> </dependency> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> On Thu, Mar 30, 2023 at 4:06 PM Endre Stølsvik < > > >>>>>> en...@stolsvik.com> > > >>>>>>>>>>>> wrote: > > >>>>>>>>>>>>> > > >>>>>>>>>>>>>> From a lurker position here, I just wanted to point out that > > >>>>>> Jetty > > >>>>>>>> is > > >>>>>>>>>>>>>> evidently making a version 12 which will support both > > >>>> javax. and > > >>>>>>>>>>>> jakarta. > > >>>>>>>>>>>>>> in the same server. > > >>>>>>>>>>>>>> https://www.eclipse.org/jetty/download.php > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Kind regards, > > >>>>>>>>>>>>>> Endre > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> On Thu, Mar 30, 2023 at 9:54 PM Jean-Baptiste Onofré < > > >>>>>>>> j...@nanthrax.net > > >>>>>>>>>>>> > > >>>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> Hi, > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> I agree with the plan but why not keep 5.19.0-SNAPSHOT on > > >>>> main > > >>>>>> ? > > >>>>>>>>>>>>>>> We have the activemq-5.18.x branch already that could be > > >>>> LTS > > >>>>>> where > > >>>>>>>> we > > >>>>>>>>>>>>>>> keep javax namespace. > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> Regards > > >>>>>>>>>>>>>>> JB > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> On Thu, Mar 30, 2023 at 7:54 PM Matt Pavlovich < > > >>>>>> mattr...@gmail.com > > >>>>>>>>> > > >>>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> Hello All- > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> I started building a jakarta-based broker for ActiveMQ > > >>>> 5.x and > > >>>>>>>>>>> propose > > >>>>>>>>>>>>>>> the following steps to manage the change. > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> Background: > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> Jakarta support in ActiveMQ 5.x is going to pull in JDK > > >>>> 17, > > >>>>>> Spring > > >>>>>>>>>>> 6, > > >>>>>>>>>>>>>>> Jakarta EE 9, Servlet 5.x, and Jetty 11. That is quite a > > >>>> bit of > > >>>>>>>>>>> change, > > >>>>>>>>>>>>>> and > > >>>>>>>>>>>>>>> I suggest we leave a ‘gap version’ in case we need to make > > >>>> any > > >>>>>>>>>>>>>> incremental > > >>>>>>>>>>>>>>> updates to 5.18.x series along the way. > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> 1. Rename main to 5.20.0-SNAPSHOT > > >>>>>>>>>>>>>>>> 2. Commit broker-related jakarta, servlet, jetty, spring, > > >>>> etc > > >>>>>>>>>>> changes > > >>>>>>>>>>>>>> to > > >>>>>>>>>>>>>>> main > > >>>>>>>>>>>>>>>> 3. Create new ‘-javax’ broker modules to support a > > >>>>>>>>>>>>>>> apache-activemq-javax-5.20.0-bin.tar.gz package using > > >>>>>> re-packaging > > >>>>>>>> of > > >>>>>>>>>>>> the > > >>>>>>>>>>>>>>> jakarta artifacts. > > >>>>>>>>>>>>>>>> 4. Leave 5.19.x as a ‘gap version’ in case it is needed > > >>>> for > > >>>>>> 5.18.x > > >>>>>>>>>>>>>>> changes > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> Thanks, > > >>>>>>>>>>>>>>>> Matt Pavlovich > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>> > > >> > > > >
