That's exactly my proposal :) +1
Regards JB On Wed, Apr 12, 2023 at 3:57 PM 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 > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >> >
